Grupo DH partilhado, segredos novos: por que o ataque fica mais barato

Os parâmetros do grupo são públicos por conceção, e é precisamente essa publicidade que os torna fáceis de ignorar. Em Diffie-Hellman sobre corpo finito, o módulo e o gerador são partilhados, enquanto os expoentes privados e as chaves de sessão resultantes não o são. A fase cara de um ataque por crivo de corpo de números depende do grupo e não de uma única troca, por isso um único grupo fraco usado em todo o lado torna-se uma responsabilidade partilhada. Chamar públicos aos parâmetros é exato e irrelevante, porque o custo que é reutilizado é o custo de atacar esse grupo.

A metade pública não é a metade vulnerável, e é aí que está a armadilha

O habitual meio-argumento diz que os parâmetros são publicados numa norma, logo um atacante já os conhece e escondê-los não mudaria nada. Ambas as afirmações são verdadeiras e nenhuma decorre da outra. Um grupo predefinido enviado é público, e um grupo privado que gerou na semana passada também é visível para quem complete o handshake. O sigilo nunca foi o controlo; são-no a força e a validação.

O que muda é quantos locais partilham a mesma fraqueza. Uma organização que gera o seu próprio grupo de 2048 bits paga o seu próprio custo de ataque, enquanto um valor predefinido de protocolo escolhido por milhões amortiza um único custo por todos eles. É nesse sentido que um grupo pouco comum não é automaticamente melhor. Um grupo invulgar que é demasiado pequeno não passa de um segredo partilhado mais pequeno com menos olhos em cima.

A validação importa tanto como o tamanho. Um par que envia um módulo com fatores pequenos, ou um que não tem a forma que o protocolo espera, pode deixar escapar informação sobre o expoente privado mesmo quando o comprimento em bits parece respeitável. As bibliotecas que rejeitam parâmetros malformados à entrada fazem trabalho real, e é por isso que a análise de parâmetros feita à mão é um mau sítio para poupar esforço.

O que o pré-cálculo realmente dá a um atacante

O crivo de corpo de números tem uma fase que depende apenas do número primo, e a sua saída é reutilizável contra cada troca que use esse primo. É todo o mecanismo por trás da preocupação histórica: a parte cara é paga uma vez, e o custo marginal de cada sessão seguinte desce. Expoentes novos ainda protegem cada troca individual de um observador passivo, desde que o grupo seja grande o suficiente para tornar o crivo inviável. As duas afirmações são compatíveis, e a maioria das discussões sobre o tema vem de escolher uma e descartar a outra.

O trabalho Logjam de 2015 demonstrou uma degradação para Diffie-Hellman de 512 bits de grau exportação e estimou o que custaria atacar grupos maiores e muito reutilizados com recursos significativos. A demonstração era concreta, as estimativas eram estimativas, e nenhuma das duas era prova de que uma sessão VPN concreta tivesse sido decifrada.

Cite o trabalho pelo mecanismo e pela degradação demonstrada, não como uma medição da sua implementação. As estatísticas antigas sobre quantos servidores partilhavam um grupo predefinido descrevem a internet desse ano, não uma rede que possa inspecionar hoje. O que vale a pena levar é a pergunta: se os seus dispositivos ainda negociam um grupo pequeno ou fracamente validado.

Normalizado não é o mesmo que fraco

O RFC 7919 define grupos de corpo finito com nome para que ambas as extremidades acordem um grupo por identificador e apliquem uma política coerente. Estar normalizado é uma vantagem, porque elimina a ambiguidade da negociação e permite a uma implementação recusar tamanhos não suportados. Um grupo com nome só é fraco quando o seu tamanho fica abaixo da política que diz seguir, e não por aparecer num documento. A mesma lógica aplica-se aos grupos de curvas elípticas, que têm uma estrutura diferente e modos de falha diferentes.

Mantenha as construções separadas quando raciocina sobre elas. Uma conclusão sobre Diffie-Hellman de corpo finito não diz nada sobre X25519, e uma conclusão sobre um grupo MODP de 1024 bits não diz nada sobre um de 3072 bits. A política de força é por mecanismo, por tamanho e por versão de protocolo, e é por isso que a frase criptografia forte não é uma afirmação revista.

A autenticação é a outra metade, e não substitui. Um grupo forte sem verificação do par deixa um atacante no meio, e um certificado válido não consegue salvar uma troca de 768 bits. Reveja-os como duas linhas independentes e depois confirme que ambos são realmente negociados.

Leia o grupo negociado numa ligação real

Leia o grupo negociado a partir do dispositivo e não do modelo de configuração. Os modelos descrevem a intenção, e o valor interessante é o que ambas as extremidades acordaram durante o último handshake. Num ponto final IPsec a saída de estado imprime normalmente a proposta selecionada, incluindo o grupo MODP.

Capture essa linha antes e depois de uma mudança de política, e guarde as duas no registo da mudança. A comparação é a prova.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Se depois da mudança o estado ainda mostrar o grupo antigo, a ligação não renegociou e a edição da configuração não provou nada. Reinicie o par ou apague a associação de segurança, e volte a ler o estado. Uma política aplicada apenas a ligações novas deixará os túneis de longa duração nos parâmetros antigos enquanto estiverem ativos.

Verifique o grupo e a identidade do par em separado

Separe o que o grupo protege de quem está do outro lado. Registe o método de troca de chaves, o tamanho do grupo e o método de autenticação como três campos, porque falham de forma independente. Um túnel que negociou um grupo de 3072 bits mas aceita qualquer certificado não é o mesmo risco que um que fixa um par e usa um grupo de 2048 bits.

Escreva os critérios de aceitação antes de a revisão começar, para que o resultado seja uma comparação e não uma opinião. Um tamanho mínimo de grupo por versão de protocolo, uma lista de autorização de grupos com nome e a verificação obrigatória do par bastam para tornar a decisão mecânica. A ambiguidade nessa lista é o que transforma uma revisão numa discussão, e as discussões não são corrigidas. Então a saída é uma lista de pontos finais que falham uma regra declarada.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Feche o ciclo relendo os valores negociados após a remediação. Um ficheiro de configuração conforme não é prova de que um túnel o tenha adotado. A saída de estado e um handshake novo são a prova, e recolhê-los leva menos tempo do que a reunião sobre se são necessários.