Um handshake VPN falhado é realmente um ataque de downgrade?

Um handshake que termina em erro parece um ataque até você olhar a mensagem, e na maioria das vezes é aritmética: nenhuma proposta compartilhada, um certificado expirado ou um pacote que nunca chegou. Um ataque de downgrade é algo específico: um adversário empurrando os dois lados para um comportamento mais fraco do que teriam escolhido, e ele deixa evidências diferentes. Tratar toda falha como malícia leva você a procurar uma vítima que talvez não exista, enquanto tratar um downgrade real como bug de configuração deixa o resultado mais fraco no lugar. Os dois erros custam coisas diferentes, e apenas um é barato de corrigir.

O que um ataque de downgrade realmente muda

O objetivo não é quebrar a cifra nem adivinhar uma chave. É influenciar a negociação para que os dois lados fiquem em uma versão mais antiga ou um algoritmo mais fraco que o atacante consiga lidar, ou fazer um lado acreditar que o outro só suporta aquilo.

O que muda é o acordo, não a autenticação. Se o atacante pode alterar a oferta sem ser detectado, os pares ainda podem concluir um handshake e ainda se autenticar, mas com parâmetros que o atacante prefere. Por isso a pergunta interessante é se a própria negociação está coberta pela proteção de integridade.

Por que a própria negociação precisa ser autenticada

O TLS 1.3 torna essa proteção explícita. Um cliente que ofereceu a versão mais nova consegue detectar um servidor que recuou em silêncio, porque o valor aleatório do servidor carrega um padrão fixo quando negocia 1.2 ou inferior, e o cliente deve abortar ao vê-lo. A transcrição completa também é coberta pelas mensagens finais, então uma edição em qualquer ponto da negociação falha mais tarde em vez de passar em silêncio.

Versões mais antigas do protocolo tinham histórias mais fracas, e é exatamente por isso que as regras de fallback importam. Um endpoint TLS 1.0 na mesma configuração não é um ataque de downgrade; é um resultado permitido que você escolheu permitir. A distinção é se o resultado mais fraco veio de uma decisão protegida ou de um caminho não protegido que um intermediário poderia influenciar. Uma vez formulado assim, a maioria dos incidentes se resolve numa questão de configuração.

O IKEv2 se comporta de forma diferente, mas repousa na mesma ideia. A proposta é transportada numa troca que depois autentica os dois pares, então um equipamento intermediário que reescreve os algoritmos quebra a autenticação em vez de conduzi-la. O canal de controle do OpenVPN protege sua negociação com TLS e depois usa esse canal para acordar as cifras do canal de dados, e é por isso que a linha de log do canal de controle é a interessante.

Compatibilidade configurada não é ataque

Um administrador pode permitir deliberadamente opções mais antigas para dar suporte a um cliente documentado, e essa decisão é visível na configuração. Um atacante não pode criar essa configuração; só pode explorar um caminho que lhe permita influenciar a oferta.

O reparo perigoso é o que remove a evidência da diferença. Habilitar todas as opções legadas, desativar a verificação de certificados ou aceitar qualquer cifra para fazer um erro desaparecer amplia o que o endpoint aceitará, e remove as verificações que teriam relatado o resultado mais fraco.

Se precisar manter uma opção antiga, nomeie o motivo e o cliente no comentário de configuração e depois limite a opção ao perfil que precisa dela. Uma exceção de compatibilidade restrita a um único listener é auditável; uma aplicada globalmente é apenas um padrão mais fraco que ninguém lembra ter escolhido.

Leia a falha antes de nomear uma causa

Preserve a string de erro exata, as versões de cliente e servidor e o horário antes de qualquer mudança. Depois classifique: os pares discordaram sobre uma proposta, o caminho dos pacotes falhou, ou um lado rejeitou um parâmetro que antes aceitava?

Uma incompatibilidade de proposta geralmente nomeia as versões ou algoritmos culpados e falha no mesmo ponto todas as vezes. Um problema de roteamento ou MTU trava ou expira, e costuma variar com a rede. Um certificado expirado produz um erro de verificação, não de negociação.

Nada disso é prova de um atacante. Atribuir causa maliciosa na primeira falha é o erro, porque esconde o bug determinístico que falhará de novo amanhã.

Confirme o que foi realmente selecionado

Depois de qualquer correção, leia o resultado negociado em vez de confiar que a conexão subiu. Uma conexão que tem sucesso porque a verificação foi removida é o resultado que você tentava evitar. Os dois comandos a seguir mostram a versão e a cifra escolhidas para um endpoint com TLS na frente, mais a linha do canal de controle do log de um servidor OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Compare o resultado com a configuração que você pretendia, não com o que agora se conecta. Se a versão selecionada for mais antiga que o mínimo permitido, o perfil ou a lista de fallback é onde olhar, e a resposta é corrigir essa lista em vez de declarar um ataque e reconstruir tudo ao redor.