tls-auth contra tls-crypt: o que cada um protege no OpenVPN

As duas opções usam um arquivo de chave compartilhado e ambas tornam o tráfego do aperto de mão mais difícil de falsificar, por isso são tratadas como dois nomes do mesmo recurso. Não são. Uma assina os pacotes de controle, a outra também os cifra, e nenhuma tem relação com a cifra que protege seus dados.

Essa distinção importa quando um perfil não consegue conectar, quando uma revisão de segurança pergunta o que a chave protege e quando alguém supõe que o arquivo extra deixa o túnel cifrado de alguma forma indefinida.

O que a chave compartilhada realmente protege

A chave usada por essas opções pertence ao canal de controle: a troca que negocia parâmetros, prova identidades e deriva as chaves de dados. É um segredo pré-compartilhado que ambas as pontas precisam ter antes de o aperto de mão prosseguir. Como fica antes das verificações de identidade, uma chave errada encerra a conversa mais cedo do que uma senha errada faria. Essa ordem explica por que o modo de falha é tão silencioso.

tls-auth usa esse segredo para calcular um HMAC sobre os pacotes de controle. Um pacote sem assinatura válida é descartado antes de chegar ao processamento TLS, mais caro, e por isso a opção costuma ser descrita como um primeiro filtro e não como substituta do TLS.

tls-crypt vai além ao cifrar o tráfego de controle protegido além de autenticá-lo. O conteúdo dos certificados, os nomes de cifra negociados e outros detalhes do aperto de mão não são mais visíveis na rede, e um observador sem a chave não consegue nem ver qual versão do TLS está sendo tentada. Para uma implantação que teme revelar sua impressão digital de VPN, essa propriedade é o motivo principal para escolhê-la. Ainda assim é um segredo de grupo, não uma credencial por usuário.

Nenhum dos mecanismos emite identidades. A chave compartilhada é um segredo de grupo, e qualquer um que a tenha pode satisfazer essa camada da verificação.

Onde as duas opções diferem

A diferença observável é o que um observador vê. Com tls-auth o aperto de mão é visível, mas não verificável sem a chave. Com tls-crypt o aperto de mão é opaco para quem não tem a chave.

A configuração também difere. tls-auth é usado com um valor de direção, então um lado usa uma metade do material da chave e o outro lado usa a outra metade. tls-crypt usa uma única chave nas duas direções, portanto a diretiva de direção não faz parte do seu arranjo.

Nas versões modernas as duas opções são mutuamente exclusivas. Um perfil deve trazer uma delas, não as duas, e o servidor e o cliente precisam concordar qual, com material de chave idêntico. Manter uma diretiva antiga ao lado de uma nova é um resíduo comum de migração. Remova a inativa para que o próximo leitor saiba qual camada está realmente em vigor.

Uma variante mais recente, tls-crypt-v2, vincula cada cliente à sua própria chave empacotada, de modo que revogar um cliente não exige reemitir a chave de grupo. Vale a pena conhecer, mas é outra opção e não um sinônimo de nenhuma das duas aqui.

Por que uma incompatibilidade parece que nada acontece

Quando o material compartilhado não confere, o outro lado descarta os pacotes sem dizer ao remetente por quê. Não há erro de autenticação para ler, porque o pacote nunca chegou à camada que o produziria.

O cliente tenta de novo, o servidor não diz nada e o sintoma parece um problema de rede. Então as pessoas reiniciam o serviço, digitam de novo a senha da conta ou removem a diretiva de proteção para «testá-la», o que muda a implantação em vez de diagnosticá-la.

Leia no log do servidor a primeira queixa em nível de pacote, e não a última linha de nova tentativa. Confirme que os dois lados trazem a mesma opção com material de chave idêntico e que o arquivo de chave não foi gerado de novo apenas em um lado.

Remover a diretiva não é um reparo seguro. Desativa uma camada de proteção para cada cliente, e um túnel que funcione depois só prova que essa camada era a incompatibilidade.

O que ainda precisa ser configurado separadamente

Essas opções não verificam quem é o outro lado. A validação de certificados, a âncora de confiança e o nome de servidor esperado continuam requisitos separados, e nenhum deles se torna opcional porque existe uma chave compartilhada.

Também não escolhem a cifra de dados. Isso é uma negociação separada controlada pelas configurações do canal de dados nos dois lados, e um túnel protegido com tls-crypt ainda pode usar uma cifra que você não pretendia.

Por fim, a própria chave compartilhada precisa de cuidado. Trate-a como segredo, distribua-a por um canal aprovado e substitua-a quando alguém que a tinha sair. Como é compartilhada, sua exposição é a exposição de cada ponta que a usa.