Cloudflare dejó de adivinar. Desde esta semana, su red mide con qué algoritmo de intercambio de llaves puede hablar cada origin server de sus clientes y arranca el handshake con ese, prefiriendo el híbrido post-cuántico X25519MLKEM768 cuando el servidor lo soporta. El resultado medido durante el rollout: los HelloRetryRequest cayeron de ~52% a 3.7% y el p90 de latencia de handshake bajó más de 150 ms.
Qué pasó
La función se llama Automatic Key Exchange (AKE) y es una extensión de Automatic SSL/TLS. Aplica a la segunda mitad del proxy: la conexión entre Cloudflare y tu origin, no la del visitante. Está activa por defecto en dominios nuevos y existentes, y se administra en el dashboard bajo SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption.
El problema que resuelve es una peculiaridad de TLS 1.3. El protocolo exige que el cliente se comprometa a un algoritmo de key agreement en el primer paquete, antes de que el servidor haya dicho nada. Si atina, el handshake cierra en un round trip. Si falla, el origin responde con un HelloRetryRequest (HRR), se empieza de nuevo y la conexión cuesta dos.
Durante años la apuesta fue la misma para todo internet: X25519. Segura, universalmente soportada y, según sus propias mediciones, subóptima para ~30% de las conexiones a origins. Más de 6% de los origins prefieren P-256 o P-384 sobre X25519, así que pagaban un round trip extra incluso en criptografía puramente clásica.
Por qué importa
La parte de los milisegundos es la que vende, pero la interesante es la otra: cientos de miles de dominios quedaron con conexiones post-cuánticas al origin sin que nadie configurara nada.
La amenaza aquí no es un ataque de mañana, es harvest-now, decrypt-later: alguien graba hoy tráfico cifrado que no puede leer, apostando a que en unos años podrá. Cloudflare se puso como meta que internet sea quantum-secure para 2029, la fecha en que parte de la industria estima que los algoritmos clásicos podrían caer — el llamado Q-Day. Y la tesis operativa detrás de AKE es la correcta: una migración criptográfica global no puede depender de que millones de operadores de sitios se vuelvan criptógrafos. Tiene que ser automática. Hasta ahora, preferir post-quantum hacia el origin era un toggle manual que se configuraba mal con facilidad; pasó a ser el default.
El detalle técnico
Cloudflare anuncia soporte de key agreement post-cuántico hacia origins desde septiembre de 2023 (primero X25519Kyber768Draft00, hoy X25519MLKEM768, la versión estandarizada). Pero anunciar soporte no es lo mismo que liderar con un keyshare: un keyshare X25519MLKEM768 pesa 1,216 bytes contra los 32 de X25519, lo que empuja el ClientHello más allá de un solo paquete de red. Y ahí aparecen los middleboxes y origins legacy que se rompen cuando el ClientHello viene partido en varios paquetes — en un estudio previo de Cloudflare, ~0.34% de los origins escaneados no lograba completar el handshake al recibir primero un keyshare post-cuántico. Por eso el HRR se usaba como red de seguridad: lento, pero nunca roto.
AKE cambia la suposición por medición, reusando el pipeline de escaneo que ya alimenta Automatic SSL/TLS:
- Contra cada origin capaz de TLS 1.3 se corren varios handshakes ligeros, cada uno ofreciendo exactamente un grupo: X25519, P-256, P-384, P-521 o X25519MLKEM768. El conjunto de respuestas revela el set completo que soporta.
- El escaneo ocurre fuera de la ruta de tráfico productivo, así que se valida que tanto el origin como la red intermedia toleren el key agreement más fuerte antes de usarlo con tráfico real.
- Si la preferencia elegida empeora la línea base de ese origin, se revierte, igual que Automatic SSL/TLS deshace un upgrade de modo de cifrado que se porta mal. El peor caso de un rollback es un round trip extra, no una conexión rota.
- Rescan diario: si mañana cambias de load balancer, tu librería TLS estrena soporte post-cuántico en un release rutinario o apagas una curva vieja, la preferencia se actualiza en el siguiente barrido.
Hay además una opción nueva de Compliance requirements para filtrar qué key agreements tiene permitido usar y anunciar Cloudflare hacia tus origins — relevante si tu marco regulatorio te ata a una lista específica.
Dos advertencias del propio anuncio que conviene no perder de vista. Primera: esto solo afecta handshakes nuevos; las requests sobre conexiones keep-alive existentes no cambian, así que el beneficio se concentra en contenido dinámico y cache misses. Segunda, y más de fondo: el key agreement post-cuántico protege la confidencialidad del tráfico, no la autenticación. Contra un adversario que use una máquina cuántica para forjar un certificado e impersonar tu origin hace falta autenticación post-cuántica — certificados ML-DSA, que en Cloudflare llegaron este año a Authenticated Origin Pulls y Custom Origin Trust Store — y ahí el pendiente son los downgrades: un origin con certificado clásico y otro ML-DSA en paralelo, para no romper clientes legacy, le da al atacante activo la ruta barata.
Qué hacer
- Si eres cliente de Cloudflare, no tienes que hacer nada — pero revisa el toggle en SSL/TLS > Overview > Configure antes de que auditoría te pregunte por qué el tráfico hacia tu origin cambió de algoritmo. Si tu compliance exige un set cerrado, configura Compliance requirements ahora, no después del hallazgo.
- Verifica si tu servidor habla post-quantum con la herramienta de Cloudflare Radar. Ojo: si metes un hostname proxeado, Radar prueba la conexión hacia Cloudflare, no hacia tu origin detrás.
- Fuera de Cloudflare la tarea es la misma y no se automatiza sola: inventaría dónde termina TLS en tu arquitectura y en qué versión están esas librerías. El cuello de botella suele ser el load balancer o el WAF de en medio, no el web server.
- Y la parte que no vende ningún vendor: inventaría qué datos tuyos seguirán siendo sensibles en 2035. Eso es lo que hoy está siendo cosechado.