Definição (cartão de glossário): tls-crypt-v2 é o modo de criptografia de canal de controle específico por cliente do OpenVPN. Cada cliente recebe uma chave tls-crypt exclusiva (Kc) mais uma cópia encapsulada dessa chave (WKc) criptografada sob uma chave compartilhada do servidor. Na conexão, o cliente envia o WKc dentro de um P_CONTROL_HARD_RESET_CLIENT_V3 pacote; o servidor desencapsula o Kc e ambos os pares passam então a criptografar os pacotes do canal de controle com a chave específica do cliente em vez de uma única chave pré-compartilhada de grupo.

Diagram comparing pre-shared key VPN authentication concepts
Fonte: Wikimedia Commons — chave pré-compartilhada Lbutrico

Quando uma tela de configurações do OpenVPN ou um FAQ de provedor menciona “tls-crypt-v2”, está nomeando um mecanismo de proteção do canal de controle, não uma cifra do canal de dados e não um protocolo VPN independente. Entender a diferença importa para frotas grandes e provedores de VPN hospedada: os clássicos --tls-auth and --tls-crypt compartilham uma chave de grupo entre todos os clientes e servidores. Se qualquer par for comprometido, essa chave compartilhada deixa de oferecer proteção significativa contra DoS e da pilha TLS para todos os outros. O tls-crypt-v2 mantém compartilhada a chave de encapsulamento do lado do servidor, ao mesmo tempo que dá a cada cliente o seu próprio Kc.

De onde vem o design

O OpenVPN documenta o recurso em doc/tls-crypt-v2.txt e na documentação da API gerada do projeto para criptografia do canal de controle (tls-crypt, tls-crypt-v2). O mesmo esquema específico do cliente aparece no rascunho OpenVPN Wire Protocol em “Chaves de criptografia específicas do cliente,” que observa explicitamente que as implementações existentes chamam o recurso de tls-crypt-v2.

A justificativa é tanto operacional quanto criptográfica. As chaves de grupo compartilhadas expiram mais rápido à medida que o número de clientes cresce, e um laptop vazado pode forçar uma redefinição em massa das chaves. Ao criptografar o Kc de cada cliente sob uma chave do servidor e enviar o WKc com o cliente, os operadores podem revogar ou rotacionar clientes individuais sem redistribuir uma única chave estática de toda a comunidade. Os servidores ainda podem aceitar tls-crypt or tls-auth clientes durante a migração porque o opcode de hard-reset V3 sinaliza o novo modo.

SSL VPN topology showing client, network, and server roles
Fonte: Wikimedia Commons — Topologia de SSL VPN

Em alto nível, o fluxo é um cookie criptografado:

  1. Os operadores criam uma tls-crypt-v2 servidor chave usada apenas para encapsular e desencapsular as chaves dos clientes.
  2. Para cada cliente, geram um Kc novo, encapsulam-no como WKc sob a chave do servidor e entregam Kc || WKc ao cliente (muitas vezes como um bloco PEM com o cabeçalho BEGIN OpenVPN tls-crypt-v2 client key).
  3. O primeiro pacote de controlo do cliente usa o opcode P_CONTROL_HARD_RESET_CLIENT_V3 e transporta WKc.
  4. O servidor desencripta WKc, carrega Kc, opcionalmente executa um tls-crypt-v2-verify script relativamente aos metadados e, a partir daí, ambos os lados usam Kc para a proteção do canal de controlo no estilo tls-crypt.

Metadados opcionais dentro do blob encapsulado podem carregar verificações de política antecipadas (por exemplo, indicações de identidade do cliente) para que um servidor possa abortar handshakes abusivos antes de gastar trabalho TLS caro. Esse aborto antecipado é um dos motivos pelos quais o recurso é promovido para resistência a DoS em sistemas grandes com múltiplos inquilinos. Grandes provedores de VPN se beneficiam especialmente porque endpoints de clientes comprometidos deixam de expor automaticamente uma única chave de grupo tls-crypt compartilhada da qual todos os outros clientes dependem para a filtragem do canal de controle.

O que o tls-crypt-v2 protege — e o que não protege

tls-crypt-v2 criptografa e autentica canal de controle pacotes: o tráfego de handshake TLS que negocia chaves de sessão e opções. Não substitui a cifra do canal de dados (AES-GCM, ChaCha20-Poly1305 e assim por diante), não escolhe IPs de saída e não implementa uma política de no-logs. Pense nisso como uma armadura em torno do plano de controle do OpenVPN para que ruído UDP não autenticado e chaves de grupo roubadas sejam menos úteis contra a stack TLS.

As notas de lançamento do OpenVPN 2.7.8 (resumidas por Linux Compatible em 7 de outubro de 2026) também mostram por que a robustez em torno do tls-crypt-v2 ainda importa: uma correção do 2.7.8 impediu que os clientes confiassem cegamente em uma solicitação do peer para reenviar uma chave de cliente encapsulada quando não havia material de chave disponível. A política CRA da Itália tratou essa classe de problema de “servidor malicioso pode interromper o cliente” como degradação de robustez em vez de uma quebra de confidencialidade digna de CVE, mas os operadores ainda querem o patch em todos os clientes que falam tls-crypt-v2.

Como difere do tls-auth e do tls-crypt

  • tls-auth: Integridade apenas HMAC nos pacotes de controle com uma chave estática compartilhada; não criptografa o canal de controle.
  • tls-crypt: Criptografa e autentica os pacotes de controle com uma única chave de grupo compartilhada.
  • tls-crypt-v2: Mesma proteção de estilo AEAD do canal de controle que o tls-crypt, mas com Kc por cliente e cookies WKc encapsulados pelo servidor.

Os três tratam do canal de controle. Confundi-los com o handshake Noise do WireGuard ou com o IKEv2 é um erro comum de glossário. O WireGuard não usa tls-crypt-v2; usuários de OpenVPN que ativam o WireGuard em outro lugar estão em uma pilha completamente diferente. Da mesma forma, ativar o tls-crypt-v2 não atualiza magicamente cifras desatualizadas do canal de dados nem corrige vazamentos de DNS fora do túnel.

Checklist prático

  1. Se você opera um servidor OpenVPN multi-cliente ou uma frota de provedor VPN, prefira tls-crypt-v2 a uma única chave tls-crypt compartilhada para que um cliente perdido não envenene a chave de grupo inteira.
  2. Mantenha a chave de encapsulamento do servidor com backup offline e rotacionável; planeje como os arquivos WKc serão reemitidos quando essa chave do servidor mudar.
  3. Confirme que os clientes realmente falam hard-reset V3 (builds modernas do OpenVPN) antes de desativar tls-auth/tls-crypt legado no servidor.
  4. Acompanhe o OpenVPN 2.7.8+ para correções de robustez do tls-crypt-v2 mesmo quando uma alteração não tiver um ID de CVE.
  5. Lembre-se: o encapsulamento forte do canal de controle não corrige uma senha de usuário reutilizada, um portal de phishing ou um vazamento de DNS fora do túnel.

Em resumo: tls-crypt-v2 é a resposta do OpenVPN a “como grandes implantações mantêm a criptografia do canal de controle sem uma chave estática compartilhada catastrófica?” Aprenda o modelo de cookies, mantenha as questões do canal de dados e de política separadas e trate a higiene de chaves por cliente como parte das operações normais de VPN, e não como uma opção exótica exclusiva para empresas.