Cloudflare acelera TLS poscuántico: el origen aún puede dejarte fuera
Cloudflare presentó el 8 de septiembre de 2026 los resultados del despliegue en curso de Automatic Key Exchange, que mide los intercambios de claves aceptados por cada origen y adelanta la opción preferida en el primer mensaje de una conexión TLS 1.3. El cambio afecta al tramo entre Cloudflare y el servidor de origen, no a la conexión independiente entre el visitante y la red de la compañía.
La función está activada para las zonas existentes y por defecto para las nuevas, pero la protección híbrida depende de que el extremo real admita X25519MLKEM768. Como resume la cobertura de SDxCentral, Cloudflare escoge ese grupo cuando encuentra compatibilidad y conserva una alternativa clásica cuando no la hay; exigir únicamente el híbrido elimina esa salida.
La primera propuesta deja de ser una conjetura fija
En TLS 1.3, Cloudflare actúa como cliente frente al origen y envía un ClientHello con una participación de clave inicial. Si el servidor acepta el grupo propuesto, el acuerdo termina en una vuelta de red; si prefiere otro de los grupos anunciados, responde con HelloRetryRequest y obliga a intercambiar un segundo ClientHello.
La selección anterior comenzaba normalmente con X25519. Automatic Key Exchange realiza sondeos fuera de la ruta del tráfico de producción y prueba por separado X25519, P-256, P-384, P-521 y X25519MLKEM768. Con esos resultados elige primero el grupo híbrido, si funciona y las reglas de cumplimiento lo permiten, o el grupo clásico compatible más conveniente.
Cloudflare comunicó en su informe del despliegue que, dentro del conjunto de orígenes ya escaneado, el 99,2% de las conexiones TLS 1.3 poscuánticas termina ahora sin HelloRetryRequest. Para el conjunto de conexiones hacia esa cohorte, la tasa de reintentos cayó aproximadamente del 52% al 3,7% y la latencia p90 del establecimiento se redujo en más de 150 milisegundos. Son mediciones agregadas del proveedor, no una mejora garantizada para cada zona.
Cuándo el híbrido elimina la segunda vuelta
El acuerdo híbrido queda completado en una sola vuelta cuando el origen y todos los componentes intermedios aceptan X25519MLKEM768. Cloudflare puede incluir entonces esa participación de clave en el ClientHello inicial, en vez de comenzar con X25519 y esperar que el servidor solicite el grupo híbrido mediante un reintento.
El ahorro solo aparece al abrir una conexión nueva. Las solicitudes que reutilizan una conexión persistente no ejecutan otro intercambio de claves. Tampoco significa que todo el tráfico de una zona pase automáticamente a ser poscuántico: si el híbrido no está disponible, el sistema puede seleccionar un grupo clásico que evite un HelloRetryRequest innecesario.
La preferencia se aplica gradualmente mientras Cloudflare observa fallos y reintentos. Una variación saludable avanza por etapas; si empeora el comportamiento respecto de la referencia del origen, el sistema recupera la preferencia anterior. Los orígenes activos se vuelven a sondear aproximadamente cada 24 horas para recoger cambios en servidores, bibliotecas TLS o infraestructura.
Forzar el híbrido puede romper todas las conexiones afectadas
La selección automática y el requisito Post-quantum hybrid cumplen funciones distintas. Sin ese filtro, Cloudflare puede anunciar y utilizar grupos clásicos compatibles. Al activarlo, la zona limita las conexiones TLS 1.3 hacia el origen exclusivamente a intercambios híbridos poscuánticos.
Si el servidor o algún terminador TLS de la ruta no admite X25519MLKEM768, las partes dejan de compartir un algoritmo permitido. El resultado no es una conexión clásica ni una vuelta adicional: fallan todas las conexiones TLS 1.3 sometidas a esa política. El control estricto impone una condición de cumplimiento, pero no actualiza las capacidades criptográficas del origen.
La incompatibilidad puede quedar oculta en una infraestructura heterogénea. Una zona puede repartir tráfico entre versiones, regiones y proveedores distintos, mientras Cloudflare deriva una sola preferencia a partir de resultados ponderados por tráfico. Un backend poco utilizado, un balanceador administrado, un WAF que inspecciona TLS o un terminador antiguo pueden convertirse en el punto de ruptura al retirar las alternativas clásicas.
La compatibilidad debe comprobarse en el terminador real
La documentación operativa de Cloudflare establece que Automatic Key Exchange está disponible en todos los planes, requiere TLS 1.3 y se aplica a zonas con los modos Full, Full (strict) o Strict (SSL-Only Origin Pull). Cloudflare Tunnel queda fuera de este mecanismo porque utiliza una conexión poscuántica separada entre cloudflared y Cloudflare.
La prueba debe apuntar al hostname o a la dirección IP que realmente termina TLS y recorrer, en lo posible, el mismo trayecto que utilizará Cloudflare. Comprobar el hostname público de una web proxificada solo examina el extremo de Cloudflare visible desde Internet; no demuestra que el origen oculto negocie X25519MLKEM768.
La validación debe abarcar cada servidor, región, balanceador, WAF, proxy o dispositivo que termine o inspeccione TLS. También importan las listas de grupos configuradas manualmente y el tratamiento de un ClientHello dividido entre segmentos: la participación de clave híbrida es mucho mayor que la de X25519 y puede revelar fallos en equipos antiguos. Solo después de confirmar el acuerdo híbrido en toda la cadena resulta seguro retirar los grupos clásicos.
El acuerdo de claves no autentica el origen
Automatic Key Exchange protege el secreto de sesión frente al riesgo de que un adversario almacene tráfico cifrado ahora para intentar descifrarlo con un ordenador cuántico en el futuro. No sustituye la autenticación del origen ni convierte un certificado RSA o ECDSA en poscuántico: el intercambio de claves y la firma del certificado cubren problemas diferentes dentro del establecimiento TLS.
El despliegue continúa mientras Cloudflare incorpora más orígenes a sus sondeos. La compañía trabaja además en preferencias por origen, análisis bajo demanda y detección de autenticación poscuántica. Hasta que esas funciones lleguen, la selección automática puede acelerar y reforzar conexiones compatibles, pero el operador sigue siendo responsable de actualizar y verificar cada componente antes de imponer exclusivamente X25519MLKEM768.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.