Criptografía post-cuántica en TLS: adopción real
Actualizado: 2026-05-03
Hace apenas dos años, la criptografía post-cuántica en TLS era una charla de conferencia, un experimento en ramas laterales de OpenSSL y un tema que quienes no nos dedicamos profesionalmente a criptografía escuchábamos con curiosidad pero sin urgencia. En septiembre de 2025 el panorama es radicalmente distinto: los grandes operadores han puesto en producción híbridos ML-KEM sobre conexiones reales de usuarios finales, la mayoría de tráfico HTTPS en navegadores modernos ya negocia algoritmos post-cuánticos, y conviene dejar de tratar el tema como ciencia ficción y empezar a revisar si nuestras propias infraestructuras están preparadas.
Puntos clave
- El punto de inflexión fue marzo 2024: Chrome activó X25519Kyber768 por defecto; Cloudflare lo negociaba desde septiembre 2023. Tras la ratificación NIST en agosto 2024, el nombre final es X25519MLKEM768.
- En julio 2025, más del 30 % de las conexiones TLS 1.3 al borde de Cloudflare negocian un grupo PQC híbrido; más del 50 % filtrando por navegadores modernos en equipos recientes.
- OpenSSL 3.5 (abril 2025) incluye ML-KEM en el árbol oficial — cualquier NGINX, Apache o HAProxy compilado contra 3.5 puede negociar el grupo híbrido sin parches externos.
- El coste: una clave pública ML-KEM-768 ocupa 1.184 bytes frente a 32 bytes de X25519 — el ClientHello supera el tamaño de un paquete TCP estándar y fuerza fragmentación en redes con middleboxes viejos.
- Las firmas digitales (ECDSA, RSA) siguen siendo clásicas — ML-DSA y SLH-DSA están ratificados pero los certificados post-cuánticos siguen siendo raros en 2025.
El cambio de fase en números
El punto de inflexión ocurrió a partir de marzo de 2024, cuando Chrome activó por defecto el grupo X25519Kyber768 en conexiones TLS 1.3 a servidores que lo soportan. Cloudflare lo había empezado a negociar desde septiembre de 2023 en su borde, y Apple lo incorporó a iMessage con PQ3 en febrero de 2024. Con la ratificación de los estándares NIST en agosto de 2024, la versión final pasó a llamarse ML-KEM-768 y el grupo híbrido en TLS se renombró a X25519MLKEM768.
Los números publicados por Cloudflare son elocuentes. A mediados de 2025, más del 30 % de las conexiones TLS 1.3 a su borde negocian un grupo post-cuántico híbrido, y esa cifra sube por encima del 50 % cuando se filtra por navegadores modernos en equipos recientes. Telemetría similar de Google y Mozilla apunta en la misma dirección.
La otra métrica que conviene mirar es la de compatibilidad en el lado servidor. OpenSSL 3.5 incluyó ML-KEM directamente en el árbol oficial en abril de 2025, lo que significa que cualquier NGINX, Apache o HAProxy compilado contra OpenSSL 3.5 o posterior puede negociar el grupo híbrido sin parches externos. Antes de esa fecha, activar PQC requería usar rutas como la librería oqs-provider de Open Quantum Safe o forks experimentales como BoringSSL.
Cómo funciona el híbrido sin mitos
Hay un malentendido extendido que conviene aclarar. ML-KEM-768 no sustituye X25519: se combina con él en lo que se llama un intercambio híbrido. El cliente y el servidor intercambian claves usando ambos algoritmos y derivan un secreto compartido a partir de los dos.
La razón es prudencia: ML-KEM es nuevo y no ha sufrido veinte años de criptoanálisis intensivo como X25519. Esta lógica de defensa en profundidad es lo que ha permitido el despliegue masivo. No es apostar toda la seguridad a un algoritmo nuevo, es sumar una capa sin retirar la existente. El beneficio es que, aunque un futuro adversario almacene tráfico cifrado hoy para descifrarlo mañana con un ordenador cuántico, el tráfico híbrido de hoy sigue siendo opaco. A esto se le llama resistencia al escenario “harvest now, decrypt later”.
El peso del handshake
El elefante en la habitación con ML-KEM es el tamaño. Una clave pública ML-KEM-768 ocupa 1.184 bytes, y el ciphertext de encapsulación otros 1.088 bytes. Comparado con los 32 bytes de una clave pública X25519, eso es un aumento de dos órdenes de magnitud. En términos prácticos, un ClientHello de TLS 1.3 con X25519MLKEM768 pesa más de dos kilobytes y puede superar el tamaño de un paquete TCP estándar, forzando fragmentación.
Esto tiene dos consecuencias notables:
-
Redes con middleboxes viejos pueden romper el handshake. Se han reportado casos aislados en routers domésticos antiguos, firewalls corporativos mal configurados y operadores móviles en países concretos. La respuesta de los navegadores ha sido implementar detección y fallback a grupos clásicos cuando el handshake con PQC falla — funciona pero introduce latencia extra en los usuarios afectados.
-
El RTT efectivo del handshake aumenta ligeramente. Medido en conexiones modernas sobre fibra con TLS 1.3 y TLS False Start, el aumento es de pocos milisegundos y prácticamente imperceptible. Medido en conexiones móviles sobre 3G en zonas con latencia alta, el aumento puede alcanzar decenas de milisegundos. Para sitios con audiencia muy móvil en zonas pobres de infraestructura, merece la pena medir antes de dar el paso.
Qué revisar en una infraestructura propia
Si administras servidores web públicos, este es un buen momento para hacer una revisión. Los puntos a mirar son relativamente simples:
Primero, la versión de OpenSSL compilada en tus servidores. Cualquier cosa por debajo de 3.5 no tiene ML-KEM nativo. Distribuciones con ciclo largo como Debian 12 todavía llevan OpenSSL 3.0, aunque Debian 13 lanzado en agosto de 2025 ya trae 3.5. En Red Hat Enterprise Linux, la situación varía por versión.
Segundo, la configuración del servidor web. NGINX acepta grupos post-cuánticos desde la versión 1.27, y aunque la configuración por defecto suele negociarlos cuando están disponibles, conviene verificar con el directivo ssl_groups incluyendo X25519MLKEM768 explícitamente. En Apache con mod_ssl y HAProxy es parecido: la opción existe pero hay que asegurar que está habilitada. Traefik — que es lo que uso en mi infraestructura — negocia automáticamente PQC cuando el OpenSSL subyacente lo soporta, sin configuración extra. Este es uno de los puntos donde la configuración automática de Dokploy sobre Traefik simplifica el despliegue de PQC para equipos pequeños.
Tercero, las métricas. Si usas Prometheus o similar, conviene añadir métricas de grupos TLS negociados para ver la proporción real de conexiones post-cuánticas. Los exportadores modernos suelen tener esto, pero no siempre está habilitado por defecto. Ver el número subir es una manera concreta de confirmar que la migración funciona.
Cuarto, las CDNs y proveedores intermedios. Si tu tráfico pasa por Cloudflare, Fastly o Akamai, la negociación PQC ocurre en el borde y tu origen no necesita cambios. Pero si tienes conexiones directas sin CDN, el esfuerzo recae en ti.
Las firmas post-cuánticas son otra historia
Un matiz importante es que el despliegue actual solo cubre el intercambio de claves con ML-KEM. Las firmas digitales, que en TLS usan certificados ECDSA o RSA, siguen siendo clásicas. Los estándares NIST para firmas post-cuánticas, ML-DSA y SLH-DSA, se ratificaron en agosto de 2024, pero los certificados post-cuánticos son todavía raros.
La razón es que una firma ML-DSA pesa varios kilobytes, lo cual encarece mucho un handshake que ya tiene certificados de cadena completa. La industria está experimentando con patrones como certificados híbridos y uso de KEMs para autenticación, pero en septiembre de 2025 no hay consenso claro. Mi previsión razonada es que ese tránsito tardará dos o tres años más en aterrizar, porque requiere coordinación entre autoridades de certificación, navegadores y operadores.
Cómo pensar la decisión
Mi lectura es que 2025 es el año en que PQC en TLS deja de ser una opción futurista para convertirse en higiene básica. No hacer nada no es neutral: significa que tu tráfico sigue siendo susceptible al escenario de recolección anticipada, con un coste de oportunidad que crece cada mes mientras el resto de la web avanza. Para cualquiera que administre infraestructura crítica, la pregunta no es si migrar sino cuándo.
La buena noticia es que el coste de migrar es bajo. Actualizar a OpenSSL 3.5, verificar la configuración del servidor web y añadir métricas es un trabajo de medio día en la mayoría de infraestructuras. La mala noticia es que las autoridades de certificación y los certificados siguen siendo clásicos, con lo que la parte de firmas del handshake queda pendiente. Pero eso es manejable mientras el intercambio de claves esté cubierto.
La recomendación concreta para quienes gestionáis algo público: revisad en los próximos meses, no en un año. La ventana para hacerlo con calma se cierra rápido, y cuando el porcentaje de tráfico post-cuántico pase del 50 al 80, quedarse con configuraciones heredadas empezará a ser un problema visible, no solo una debilidad teórica.
