Chaves de 8192 bits travam o handshake; DH de 1024 bits é recusado

Um servidor tem clientes que travam por um tempo e depois se reconectam, e outro recusa conexões de imediato com uma mensagem sobre o tamanho da chave. Parecem bugs diferentes e são o mesmo bug apontando em direções opostas. A criptografia do handshake tem um custo que cresce com o tamanho dos parâmetros, e também tem um piso abaixo do qual as bibliotecas modernas não descem. Dimensionar o material é a lista de verificação, e o primeiro item é decidir qual das duas falhas você realmente tem.

Leia a falha antes de regenerar qualquer coisa

O tempo diz a maior parte. Um handshake que consome vários segundos e depois morre costuma significar que o cálculo superou a paciência do par, o que aponta para parâmetros grandes demais para o hardware ou para o tempo limite. Uma recusa imediata que nomeia um tamanho de chave ou de grupo aponta para o outro lado, para material que a biblioteca não aceitará de jeito nenhum.

Esses dois precisam de correções opostas, e é aqui que a maioria das tentativas erra. Regenerar parâmetros de 8192 bits num cliente que já recusou um grupo pequeno piora o caso lento sem fazer nada pelo rápido. Anote qual sintoma você observou antes de tocar num arquivo.

Depois verifique o que se pede ao par. Um servidor configurado para um grupo grande de campo finito obriga cada cliente a gastar o mesmo tempo de CPU em cada renegociação, não só ao conectar. Se o problema aparece em intervalo regular em vez de na inicialização, esse intervalo é uma pista forte de qual configuração é caro. A renegociação repete todo o cálculo, então um travamento que volta a cada hora costuma ser o mesmo custo pago de novo.

O caso lento: material que o hardware não pode pagar

O trabalho de Diffie-Hellman e RSA cresce rápido com o tamanho da chave, e tudo isso acontece antes de qualquer tráfego fluir pelo túnel. Num roteador pequeno ou num cliente de baixa potência, um grupo grande o bastante pode empurrar a troca para além do tempo limite do outro lado, de modo que a conexão tenta de novo ou simplesmente parece travada sem erro algum.

A correção é descer para um tamanho que todo par suporte e todo dispositivo consiga calcular com folga. Uma chave RSA de 2048 bits e um grupo de 2048 bits continuam sendo uma base amplamente compatível; ir além só ajuda quando todos os pares concordam e a CPU consegue pagar em cada renegociação. Tudo o que passa dessa base é uma troca deliberada, não uma melhoria.

Tamanho não é pontuação, e o maior número de uma tabela de comparação não é automaticamente a escolha correta. Escolha o menor valor que sua política permite e que todos os pares aceitam, e então meça o handshake em vez de supor que melhorou. Um grupo menor que ainda estoura o tempo diz que o tamanho nunca foi a história inteira.

O caso rápido: um grupo que a biblioteca recusa

Compilações modernas do OpenSSL recusam de imediato os menores grupos de campo finito, e um nível de segurança elevado empurra o piso ainda mais para cima. O firmware de roteador que traz um arquivo de parâmetros de décadas é a fonte habitual, e o sintoma é uma conexão que falha na hora com uma mensagem que nomeia o grupo ou o tamanho da chave. Nada nessa falha é intermitente, e é isso que a torna fácil de reconhecer.

Substitua o arquivo em vez de editar a configuração para pular a verificação. Gere um grupo atual, valide-o e instale-o onde o daemon realmente o lê. Mantenha o arquivo antigo até um cliente se conectar com sucesso com o novo:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

O comando de verificação valida o arquivo e não imprime nada útil quando passa; a listagem confirma que você substituiu o arquivo que o serviço carrega, e não uma cópia velha ao lado. Aponte a configuração para esse caminho, reinicie o daemon e confirme que um cliente que falhava antes agora conclui o handshake.

Se o servidor também define um nível de segurança ou um perfil de certificado, leia-os antes de concluir que o grupo estava errado. Um perfil que exige uma classe mais estrita pode recusar material que o padrão teria aceitado, e remover essa configuração é uma mudança mais estreita do que desligar a verificação globalmente.

Escolha um tamanho para o par e o hardware

Descubra o que a ponta remota aguenta antes de gerar algo exótico. Um dispositivo velho demais para um grupo de 2048 bits é um dispositivo a substituir, já que apontar o servidor para um grupo mais fraco só converte uma reclamação de compatibilidade em queda. Correções duradouras caminham para software mais novo, não para parâmetros mais velhos. Toda exceção temporária nesse campo tem o hábito de virar a configuração permanente.

Onde a CPU do servidor é o limite, mude o algoritmo em vez de descer abaixo da política. Uma troca de chaves de curva elíptica como o X25519 é muito mais barata que um grupo grande de campo finito e tem amplo suporte, o que a torna a melhor resposta a uma reclamação de desempenho do que um módulo RSA menor.

Escolha o que escolher, teste com uma conexão real e observe quanto tempo o handshake leva, não apenas se no fim conecta. Uma conexão que tem sucesso em doze segundos tem a mesma causa raiz que uma que falha aos quinze.

Registre a escolha para que uma reconstrução não a desfaça

Mantenha o arquivo de parâmetros sob gestão de configuração e escreva ao lado o tamanho, o motivo e a data. Um servidor reconstruído que gera em silêncio seus próprios padrões é a forma como a mesma falha volta seis meses depois sem que ninguém consiga explicar a decisão original.

Anote as mesmas informações junto ao endpoint e ao perfil, para que uma revisão não precise reconstruí-las a partir do tamanho de um arquivo. Quando a próxima conexão travar, essa nota é a diferença entre uma verificação de cinco minutos e uma nova investigação. Também impede o próximo engenheiro de resolver o caso lento com uma correção pensada para o rápido.