Como verificar se uma conexão TLS realmente negociou X25519MLKEM768

Objetivo

Situação em 25 de outubro de 2026. Determinar qual grupo de troca de chaves foi selecionado por uma conexão TLS específica. Após atualizações, conferir novamente os grupos padrão da biblioteca implantada, as políticas do navegador e a configuração de terminação TLS. X25519MLKEM768 combina o X25519 clássico com ML-KEM; sua presença em uma configuração indica uma capacidade, não o resultado de uma conexão.

Pré-requisitos

Usar um endpoint sob sua administração, seu nome de host DNS e seu repositório normal de certificados confiáveis. A documentação do OpenSSL 3.5 registra suporte a ML-KEM e o envio de uma parcela de chave híbrida por padrão. O relatório do Chromium do quarto trimestre de 2024 registra a ativação padrão de ML-KEM a partir do Chrome 131 nas plataformas listadas. Ambos os endpoints devem suportar um grupo em comum; configurações explícitas podem alterar o resultado. Esses são marcos de disponibilidade das funcionalidades, não recomendações para instalar versões antigas.

Passos

1. Registrar a compilação do cliente, o destino, o horário e o caminho de rede. Verificar se a conexão termina em uma aplicação, em um proxy reverso ou em um gateway de inspeção. Tratar cada trecho com terminação independente como um item separado do inventário.

2. No Chrome DevTools, abrir o painel Privacidade e segurança e selecionar a origem relevante em Segurança. Inspecionar os detalhes da conexão e registrar o grupo de troca de chaves, se exibido. A visualização de um certificado ou um indicador genérico de conexão segura não é suficiente. A documentação citada do painel foi atualizada pela última vez em 27 de fevereiro de 2025; os rótulos podem mudar entre compilações.

3. Com uma compilação adequada do OpenSSL, estabelecer uma nova conexão em um terminal interativo usando as configurações padrão. Substituir o nome de host de exemplo em todas as ocorrências:

   openssl s_client -connect service.example:443 -servername service.example \
     -tls1_3 -verify_hostname service.example -verify_return_error -brief
   

   Aguardar o resumo do handshake, registrar o grupo negociado e o resultado da verificação do certificado e encerrar a sondagem com Ctrl-C. Repetir com -groups X25519MLKEM768. A conclusão bem-sucedida usando apenas esse grupo comprova suporte no caminho testado. Não comprova o que os clientes comuns selecionam. Fornecer o arquivo de CA adequado para um domínio privado de confiança; manter a verificação do nome do host.

4. Verificar curl --version para identificar seu backend TLS. Em uma compilação baseada em OpenSSL que suporte o grupo, comparar uma requisição comum com:

   curl --verbose --tlsv1.3 --tls-max 1.3 --curves X25519MLKEM768 \
     --output /dev/null https://service.example/
   

   A configuração explícita de grupos do Curl substitui a lista padrão do backend. Preservar as verificações de certificado e inspecionar o resultado do handshake; uma falha isolada não permite distinguir grupos sem suporte de problemas de conexão sem relação com eles. Não presumir que todos os backends exibam os mesmos campos de diagnóstico.

5. Correlacionar a conexão com a telemetria do servidor. Quando possível, registrar o grupo selecionado, em vez da lista configurada ou oferecida. O OpenSSL expõe SSL_get_negotiated_group() para essa finalidade. Se o servidor não tiver essa telemetria, registrar a lacuna em vez de interpretar nomes de suítes criptográficas como evidência do grupo.

Resultado esperado

O registro distingue a seleção padrão, o suporte ao grupo forçado e os caminhos não verificados. Manter a autenticação por certificado e a troca de chaves como constatações separadas. Repetir ambas as verificações após alterar uma restrição de grupos ou atualizar um terminador TLS.

Limites e base de verificação

Este é um procedimento baseado em documentação; não se afirma ter medido endpoints. Uma conexão do navegador e uma sondagem TCP por linha de comando podem percorrer caminhos diferentes. A reutilização de sessões também pode ocultar uma nova troca. O OpenSSL documenta que parcelas de chave híbrida maiores podem revelar falhas em equipamentos intermediários. Diagnosticar essas falhas antes de aceitar uma exceção permanente que permita apenas criptografia clássica.