Cómo comprobar si una conexión TLS negoció realmente X25519MLKEM768

Objetivo

Estado al 25 de octubre de 2026. Determinar qué grupo de intercambio de claves seleccionó una conexión TLS concreta. Volver a comprobar los grupos predeterminados de la biblioteca desplegada, las políticas del navegador y la configuración de terminación TLS después de las actualizaciones. X25519MLKEM768 combina el algoritmo clásico X25519 con ML-KEM; su presencia en una configuración declara una capacidad, no el resultado de una conexión.

Requisitos previos

Utilizar un endpoint bajo administración propia, su nombre de host DNS y su almacén habitual de certificados de confianza. La documentación de OpenSSL 3.5 recoge el soporte de ML-KEM y el envío predeterminado de material de intercambio de claves híbrido. El informe de Chromium del cuarto trimestre de 2024 indica que ML-KEM está habilitado de forma predeterminada desde Chrome 131 en las plataformas enumeradas. Ambos extremos deben admitir un grupo común; los ajustes explícitos pueden cambiar el resultado. Estas versiones son referencias de disponibilidad de funciones, no recomendaciones de instalar versiones antiguas.

Pasos

1. Registrar la compilación del cliente, el destino, la hora y la ruta de red. Comprobar si la conexión termina en una aplicación, un proxy inverso o una pasarela de inspección. Tratar cada tramo con terminación independiente como un elemento separado del inventario.

2. En Chrome DevTools, abrir el panel Privacidad y seguridad y seleccionar el origen correspondiente en Seguridad. Inspeccionar los detalles de su conexión y registrar el grupo de intercambio de claves si se muestra. Una vista del certificado o un indicador genérico de conexión segura no bastan. La documentación citada del panel se actualizó por última vez el 27 de febrero de 2025; las etiquetas pueden cambiar entre compilaciones.

3. Con una compilación adecuada de OpenSSL, establecer una conexión nueva en un terminal interactivo utilizando sus valores predeterminados. Sustituir el nombre de host de ejemplo en todas sus apariciones:

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

   Esperar el resumen de la negociación, registrar el grupo negociado y el resultado de la verificación del certificado y, después, cerrar la prueba con Ctrl-C. Repetir con -groups X25519MLKEM768. Si se completa correctamente con ese único grupo, queda demostrado que la ruta probada lo admite. Esto no demuestra qué seleccionan los clientes habituales. Proporcionar el archivo de CA adecuado para un dominio de confianza privado; mantener la verificación del nombre de host.

4. Consultar curl --version para identificar su backend TLS. En una compilación basada en OpenSSL que admita el grupo, comparar una solicitud ordinaria con:

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

   La selección explícita de grupos de curl sustituye la lista predeterminada del backend. Conservar las comprobaciones de certificados e inspeccionar el resultado de la negociación; un fallo por sí solo no permite distinguir los grupos no admitidos de otros problemas de conexión. No asumir que todos los backends muestran los mismos campos de diagnóstico.

5. Correlacionar la conexión con la telemetría del servidor. Donde sea posible, registrar el grupo seleccionado en lugar de la lista configurada u ofrecida. OpenSSL expone SSL_get_negotiated_group() para este fin. Si el servidor carece de esa telemetría, registrar la carencia en lugar de interpretar los nombres de las suites de cifrado como prueba del grupo utilizado.

Resultado esperado

El registro distingue la selección predeterminada, el soporte de un grupo forzado y las rutas no verificadas. Mantener la autenticación mediante certificados y el intercambio de claves como hallazgos independientes. Repetir ambas comprobaciones después de cambiar una restricción de grupos o de actualizar un componente que termine TLS.

Límites y base de verificación

Este procedimiento se basa en documentación; no se afirma haber realizado mediciones de ningún endpoint. Una conexión de navegador y una prueba TCP desde la línea de comandos pueden recorrer rutas diferentes. La reutilización de sesiones también puede dificultar la observación de un intercambio nuevo. OpenSSL documenta que el mayor tamaño del material de intercambio de claves híbrido puede poner de manifiesto fallos en dispositivos intermedios. Diagnosticar esos fallos antes de aceptar una excepción permanente limitada a algoritmos clásicos.