Cómo verificar que tu configuración esté lista para la criptografía poscuántica

Esta entrada asume familiaridad con los conceptos básicos de PQC. Si quieres el contexto previo, empieza por la primera parte.

El TLS 1.3 handshake con ML-KEM híbrido

TLS 1.3 es el protocolo que protege la gran mayoría del tráfico HTTPS actual. A diferencia de TLS 1.2, reduce el número de round-trips del handshake y elimina varios mecanismos heredados que eran fuente de vulnerabilidades. El handshake básico funciona así:

1. El cliente envía un ClientHello con los algoritmos que soporta y una clave pública efímera (key share).
2. El servidor responde con un ServerHello seleccionando los parámetros criptográficos, su propio key share y el certificado firmado.
3. Ambas partes derivan el secreto compartido a partir de los key shares intercambiados.
4. De ese secreto se generan las claves de sesión que cifrarán el tráfico.

El punto crítico desde la perspectiva PQC está en el paso de acuerdo de claves. Con un modelo híbrido, cliente y servidor intercambian key shares de ML-KEM junto con los de ECDHE clásico. La clave de sesión se deriva del algoritmo más seguro que soporte el cliente. Hoy la  mayoría del tráfico TLS ya viaja con ML-KEM activo, impulsado por el soporte nativo de Chrome, Firefox y Edge y mantiene el tradicional para garantizar la compatibilidad con los dispositivos más antiguos. Este enfoque híbrido es el que ha adoptado la industria porque no degrada la seguridad existente mientras añade resistencia cuántica.

Rendimiento e impacto en la red

En cuanto al impacto en la red, la adopción de PQC conlleva un ligero incremento en el tamaño de los paquetes durante el intercambio inicial de claves. No obstante, las pruebas de rendimiento indican que para la mayoría de las aplicaciones web y sitios de contenido, el impacto en la latencia es mínimo y queda compensado por la optimización de TLS 1.3 y la terminación cercana al usuario que ofrecen las redes de distribución de contenido.

Los key shares de ML-KEM añaden entre 1 y 2 KB al handshake TLS respecto a ECDHE puro. En conexiones de duración normal esto es marginal. Donde puede ser más perceptible es en entornos con alto volumen de conexiones TLS muy cortas o con restricciones de ancho de banda.

El mayor impacto potencial no está en el key agreement sino en los certificados poscuánticos. Los certificados basados en ML-DSA o SLH-DSA pueden ser entre 10 y 50 veces más grandes que los actuales basados en ECDSA, con implicaciones directas en el tamaño del handshake y en dispositivos de red intermedios que inspeccionan tráfico TLS. Es precisamente por esto que la industria ha priorizado la migración del key agreement: el coste de rendimiento es bajo y la ganancia frente a HNDL (Harvest now, decrypt later) es inmediata.

Las CDN, con su red distribuida, tienen ventaja estructural ya que terminan TLS cerca del usuario final, lo que absorbe buena parte de la latencia adicional del handshake independientemente del tamaño de los paquetes intercambiados.

Cómo verificar que tu servidor de origen está listo para el key agreement poscuántico

Para aquellos equipos técnicos que deseen verificar su preparación, existen herramientas para comprobar si el origin server está configurado correctamente para el acuerdo de claves poscuánticas.

El primer paso es confirmar que tu servidor está negociando TLS 1.3. ML-KEM solo está disponible en TLS 1.3; si el servidor cae a TLS 1.2, no hay soporte PQC posible en ese tramo.

Para comprobar qué grupos de claves está ofreciendo tu servidor puedes usar OpenSSL desde la línea de comandos:

openssl s_client -connect tu-servidor.com:443 -tls1_3

En la salida, busca referencias a X25519MLKEM768 o SecP256r1MLKEM768. Estos son los grupos híbridos ML-KEM más habituales en implementaciones actuales. Si no aparecen, el servidor no está ofreciendo soporte PQC en el key agreement.

Otras opciones: el SSL Labs Server Test de Qualys incluye en sus versiones recientes información sobre soporte de grupos poscuánticos. En Chrome, puedes revisar el campo key_exchange_group en chrome://net-internals/#events durante una conexión TLS activa.

Recomendaciones

Incluye soporte PQC como requisito en cualquier proceso de contratación de proveedores de CDN, WAF o servicios TLS. Si un proveedor no tiene una posición clara sobre su roadmap de migración, eso es información relevante para tu decisión.

También:

• Automatiza la emisión y renovación de certificados. La agilidad en la gestión de certificados es un prerrequisito para poder migrar a certificados poscuánticos cuando el ecosistema esté listo, y es una práctica que reduce riesgos operativos independientemente de la computación cuántica.
• Deshabilita TLS 1.1 y TLS 1.2 donde sea posible. Estas versiones no usan algoritmos PQC y amplían la superficie de ataque innecesariamente.
• Evalúa con tiempo a los proveedores críticos. Si un proveedor falla en la transición a PQC, el impacto puede ser significativo. Es mejor identificar esos riesgos antes de que sean urgentes.

Para datos con una vida útil larga considera que la ventana de exposición HNDL ya está abierta si ese tráfico no viaja protegido con PQC. El momento de actuar no es cuando los ordenadores cuánticos lleguen, sino antes de que lleguen.

Transparent Edge ya securiza la comunicación entre navegador y los nodos edge utilizando cifrado en criptografía poscuántica. Protegemos tu futuro desde el presente. Contacta con nuestro departamento de soporte al cliente para más información.

Sonia Arévalo es Product Marketing Manager en Transparent Edge.

Cómo acabó una Analista de Sistemas estudiando Tecnología de los Alimentos es complicado de explicar. Si le añades que luego decidió dedicarse al Marketing Digital, ya es un enigma completo que esta chica haga tantas cosas bien. Más argentina que el asado, Sonia mantiene nuestra web y redes sociales traduciendo el élfico lenguaje técnico a algo asimilable para la gente normal. “Excelente” es su interjección favorita, que hace juego con su trabajo.