Um site está pronto para a era pós-quântica, na parte que mais importa hoje, quando seu servidor consegue acordar chaves de sessão usando uma troca de chaves pós-quântica híbrida. A opção mais implantada é o X25519MLKEM768, que combina o X25519 clássico com o ML-KEM-768, o mecanismo de encapsulamento de chaves padronizado pelo NIST no FIPS 203. Ele está registrado na IANA como grupo TLS 0x11EC e é o único grupo pós-quântico que a IANA marca como recomendado.
Por que começar pela troca de chaves? Por causa do harvest now, decrypt later (colete agora, decifre depois): um atacante pode gravar tráfego criptografado hoje e decifrá-lo quando existir um computador quântico de grande porte. Apenas a troca de chaves protege o tráfego gravado. Certificados e assinaturas também importam, mas uma assinatura precisa ser forjada em tempo real, então eles podem migrar depois.
Método 1: uma análise online
A forma mais rápida é informar o domínio no scanner da PQC Status. Ele oferece ao servidor cada grupo pós-quântico padronizado, um por um, e informa quais são aceitos, qual grupo um navegador moderno realmente obtém, as versões de TLS e suítes de cifras e a cadeia de certificados. Leva poucos segundos e não exige acesso ao servidor.
Método 2: um comando OpenSSL
Com o OpenSSL 3.5 ou posterior (verifique com openssl version), ofereça apenas o grupo híbrido. Se o servidor o suportar, o handshake é concluído; caso contrário, ele falha:
openssl s_client -connect example.com:443 -servername example.com \
-groups X25519MLKEM768 -brief </dev/nullUm servidor pronto para a era pós-quântica responde com uma linha como:
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768Um servidor que só suporta grupos clássicos encerra o handshake com um alerta, normalmente ssl/tls alert handshake failure (alerta número 40). Observe que o s_client termina com status 0 nos dois casos: leia a saída, não o código de retorno.
Para testar os outros grupos híbridos, substitua o nome do grupo por SecP256r1MLKEM768 ou SecP384r1MLKEM1024. Este último é a opção de nível 5 que a ANSSI prefere sempre que possível.
Método 3: o navegador
As versões atuais do Chrome, do Edge e do Firefox oferecem X25519MLKEM768 por padrão. Em navegadores baseados no Chromium, abra as ferramentas de desenvolvedor, vá ao painel Security e veja os detalhes da conexão: a linha da troca de chaves indica o grupo negociado. Isso mostra o que o seu próprio navegador obteve, o que é útil para uma verificação rápida, mas depende da versão do navegador.
Interpretando o resultado corretamente
Uma CDN pode esconder sua origem
Se o seu site está atrás da Cloudflare, Fastly, CloudFront ou de outra CDN, todo teste externo vê a borda, não o seu servidor. Muitas CDNs ativam a troca de chaves híbrida por padrão na borda, então o site parece pronto. A conexão da CDN até o seu servidor de origem é um link TLS separado, que pode ainda usar apenas troca de chaves clássica. Teste a origem diretamente, a partir de uma máquina autorizada a acessá-la, com o comando OpenSSL acima.
O TLS 1.3 é pré-requisito
A troca de chaves híbrida só existe no TLS 1.3. Um servidor limitado ao TLS 1.2 não pode estar pronto para a era pós-quântica, qualquer que seja o seu certificado. O memorando M-26-15 do OMB dos EUA também exige TLS 1.3 para sistemas federais até janeiro de 2030.
Certificados clássicos são normais hoje
Seu certificado quase certamente usa RSA ou ECDSA. Isso é esperado: as autoridades certificadoras públicas ainda não emitem certificados pós-quânticos para a web. Registre o algoritmo do certificado no seu inventário, mas não o trate como um impedimento para a etapa da troca de chaves.
Rascunhos antigos do Kyber não contam
Algumas implantações iniciais usaram X25519Kyber768Draft00, uma versão pré-padrão do algoritmo. Ela está obsoleta: os servidores devem migrar para os grupos ML-KEM padronizados.
O que fazer se a resposta for não
- Verifique a biblioteca TLS: OpenSSL 3.5 ou posterior, ou uma biblioteca equivalente com suporte ao ML-KEM.
- Ative o grupo híbrido no seu servidor web ou balanceador de carga, mantendo o X25519 como fallback. Nosso guia para ativar o ML-KEM no nginx, Apache, HAProxy e Caddy traz as diretivas exatas.
- Execute o teste novamente e adicione o resultado, com a data, ao seu inventário criptográfico.