Un sitio web está preparado para la criptografía poscuántica, en la parte que más importa hoy, cuando su servidor puede acordar las claves de sesión mediante un intercambio de claves poscuántico híbrido. La opción más desplegada es X25519MLKEM768, que combina el X25519 clásico con ML-KEM-768, el mecanismo de encapsulación de claves estandarizado por el NIST en FIPS 203. La IANA lo tiene registrado como grupo TLS 0x11EC y es el único grupo poscuántico que la IANA marca como recomendado.
¿Por qué empezar por el intercambio de claves? Por los ataques «almacenar ahora, descifrar después»: un atacante puede registrar hoy tráfico cifrado y descifrarlo cuando exista un ordenador cuántico de gran capacidad. Solo el intercambio de claves protege el tráfico registrado. Los certificados y las firmas también importan, pero una firma debe falsificarse en tiempo real, por lo que pueden migrarse más adelante.
Método 1: un análisis en línea
La forma más rápida es introducir el dominio en el escáner de PQC Status. Ofrece al servidor cada grupo poscuántico estandarizado, uno por uno, e indica cuáles se aceptan, qué grupo obtiene realmente un navegador moderno, las versiones de TLS y los conjuntos de cifrado, y la cadena de certificados. Tarda unos segundos y no requiere acceso al servidor.
Método 2: un único comando de OpenSSL
Con OpenSSL 3.5 o posterior (compruébelo con openssl version), ofrezca únicamente el grupo híbrido. Si el servidor lo admite, la negociación se completa; si no, falla:
openssl s_client -connect example.com:443 -servername example.com \
-groups X25519MLKEM768 -brief </dev/nullUn servidor preparado para la criptografía poscuántica responde con una línea como esta:
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768Un servidor que solo admite grupos clásicos termina la negociación con una alerta, normalmente ssl/tls alert handshake failure (alerta número 40). Tenga en cuenta que s_client termina con el código de salida 0 en ambos casos: lea la salida, no el código de salida.
Para probar los demás grupos híbridos, sustituya el nombre del grupo por SecP256r1MLKEM768 o SecP384r1MLKEM1024. Este último es la opción de nivel 5 que la ANSSI prefiere siempre que sea posible.
Método 3: el navegador
Las versiones actuales de Chrome, Edge y Firefox ofrecen X25519MLKEM768 por defecto. En los navegadores basados en Chromium, abra las herramientas para desarrolladores, vaya al panel Seguridad y consulte los detalles de la conexión: la línea del intercambio de claves indica el grupo negociado. Esto muestra lo que ha obtenido su propio navegador, lo cual resulta útil para una comprobación rápida, pero depende de la versión del navegador.
Interpretar correctamente el resultado
Una CDN puede ocultar su origen
Si su sitio está detrás de Cloudflare, Fastly, CloudFront u otra CDN, cualquier prueba externa ve el borde, no su servidor. Muchas CDN activan por defecto el intercambio de claves híbrido en el borde, por lo que el sitio parece preparado. La conexión entre la CDN y su servidor de origen es un enlace TLS independiente que puede seguir usando únicamente un intercambio de claves clásico. Pruebe el origen directamente, desde una máquina autorizada a acceder a él, con el comando de OpenSSL anterior.
TLS 1.3 es un requisito previo
El intercambio de claves híbrido solo existe en TLS 1.3. Un servidor limitado a TLS 1.2 no puede estar preparado para la criptografía poscuántica, sea cual sea su certificado. El memorando M-26-15 de la OMB de EE. UU. también exige TLS 1.3 para los sistemas federales antes de enero de 2030.
Los certificados clásicos son normales hoy
Es casi seguro que su certificado utiliza RSA o ECDSA. Es lo esperable: las autoridades de certificación públicas todavía no emiten certificados poscuánticos para la web. Registre el algoritmo del certificado en su inventario, pero no lo considere un obstáculo para la etapa del intercambio de claves.
Los antiguos borradores de Kyber no cuentan
Algunos despliegues tempranos utilizaban X25519Kyber768Draft00, una versión del algoritmo anterior a la norma. Está obsoleta: los servidores deberían pasar a los grupos ML-KEM estandarizados.
Qué hacer si la respuesta es no
- Compruebe la biblioteca TLS: OpenSSL 3.5 o posterior, o una biblioteca equivalente compatible con ML-KEM.
- Active el grupo híbrido en su servidor web o balanceador de carga, manteniendo X25519 como alternativa. Nuestra guía para activar ML-KEM en nginx, Apache, HAProxy y Caddy incluye las directivas exactas.
- Vuelva a ejecutar la prueba y añada el resultado, con su fecha, a su inventario criptográfico.