Cloudflare: ve qué tráfico de tu dominio ya es post-quantum

Qué lanzó Cloudflare y por qué importa a cualquier startup con tráfico web

Cloudflare abrió dentro de su plataforma la posibilidad de ver, dominio por dominio, qué fracción del tráfico entrante ya negocia cifrado post-quantum. Los nuevos campos aparecen en el dashboard de HTTP Traffic Analytics, en Logpush y en Log Explorer, y exponen el algoritmo de intercambio de claves usado en cada conexión TLS 1.3. Hasta ahora, esa información sólo estaba disponible de forma agregada en Cloudflare Radar; ahora cualquier cliente puede hacer la pregunta que su equipo de seguridad o su auditor llevaba meses esperando responder: ¿qué porcentaje del tráfico a www.mi-startup.com está realmente protegido contra un adversario cuántico?

El algoritmo que Cloudflare considera "post-quantum" en TLS 1.3 es el híbrido X25519MLKEM768, que combina el intercambio clásico ECDHE sobre la curva X25519 con el post-quantum Module Lattice Key Encapsulation Mechanism (ML-KEM), estandarizado por NIST como FIPS 203. Como reporta el blog oficial de Cloudflare, hoy alrededor del 70% del tráfico generado por navegadores que llega a la red de Cloudflare ya negocia este algoritmo híbrido, mientras que sólo cerca del 15% de los servidores de origen (Cloudflare-to-origin) a los que se conecta la plataforma lo soportan.

Por qué 2026 ya es tarde si tus datos importan dentro de 10 años

El cifrado post-quantum no es un proyecto para el próximo lustro: es una respuesta defensiva que ya está en marcha. Cloudflare mismo se puso como meta interna 2029 para completar la migración a criptografía post-quantum (cifrado y autenticación), un año antes que la fecha regulatoria de Estados Unidos. La Executive Order 14409, firmada el 22 de junio de 2026, fija el 31 de diciembre de 2030 como límite para que las agencias federales migren sus sistemas más sensibles a cifrado post-quantum, y el 31 de diciembre de 2031 para completar la migración a autenticación post-quantum (Tech Times).

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El motivo de la urgencia es que el ataque ya empezó. La propia orden ejecutiva reconoce que adversarios están recolectando datos cifrados hoy para descifrarlos cuando aparezca una computadora cuántica criptográficamente relevante. Es lo que la industria llama harvest now, decrypt later: si tu tráfico transporta datos cuyo valor sigue vivo en 2034 (contratos, datos clínicos, propiedad intelectual, historiales financieros, credenciales), alguien los puede estar archivando ya, y no necesitas un ordenador cuántico para interceptarlos.

Qué información concreta puedes ver a partir de hoy

El nuevo campo en logs y dashboards es ClientTLSKeyExchangeGroup para la conexión visitante-a-Cloudflare, y OriginTLSKeyExchangeGroup para la conexión Cloudflare-a-origen. Esto es lo que un founder o un DevOps puede auditar a partir de ahora:

Tráfico en X25519MLKEM768: protegido con post-quantum. Si es mayoría, vas bien.
Tráfico en X25519, P-256 o P-384: cifrado clásico (ECDHE). Funciona hoy, pero es vulnerable a Q-day.
Tráfico marcado como "None": usa RSA key agreement (TLS 1.2 o inferior) o directamente nada de TLS. Esto ya es un agujero de seguridad actual, no sólo cuántico.
X25519Kyber768Draft00: el algoritmo experimental que Cloudflare desplegó antes de que la IETF estandarizara la versión final. Apenas queda tráfico residual; Cloudflare ha esperado a retirarlo hasta confirmar que las conexiones son mínimas para no romper clientes legacy.

La instrucción práctica del propio equipo de Cloudflare es directa: si tu dominio no muestra nada de X25519MLKEM768, el primer paso es comprobar que TLS 1.3 está activado en SSL/TLS > Edge Certificates. No hay un interruptor separado de post-quantum: cuando TLS 1.3 está activo y el visitante lo soporta, la negociación del algoritmo híbrido es automática.

El otro lado de la historia: autenticación post-quantum

El cifrado es sólo la primera mitad del problema. La segunda mitad es la autenticación: cambiar los certificados y firmas digitales que usan RSA y ECDSA por algoritmos post-quantum como ML-DSA (FIPS 204). Y aquí la ingeniería se complica: según el análisis de Cloudflare recogido por Tech Times, una firma ML-DSA ocupa entre 2.420 y 4.595 bytes, frente a los 64 bytes de una firma ECDSA actual. Eso es un crecimiento de 38 a 72 veces.

Este salto de tamaño tiene consecuencias prácticas inmediatas:

En pruebas internas de Cloudflare, alrededor del 5% de las conexiones fallan porque middleboxes (firewalls, balanceadores, IDS) no manejan registros TLS tan grandes.
Las conexiones que sí completan son más lentas: los paquetes exceden la ventana inicial de congestión de TCP y fuerzan round-trips extra.
La cadena de dependencias es mayor: hay que actualizar clientes, servidores, autoridades certificadoras, logs de Certificate Transparency, root stores y navegadores al mismo tiempo, porque la PKI es una jerarquía interbloqueada. La misma cadena firma actualizaciones de software y firmware: un adversario cuántico no sólo podría suplantar webs, también firmar binarios maliciosos que parecerían legítimos a sistemas sin migrar.

La solución que Cloudflare está probando con Google Chrome son los Merkle Tree Certificates (MTC), que agrupan una firma post-quantum entre miles de certificados en lugar de firmar cada uno individualmente. Cloudflare anunció hoy mismo que lanzará una autoridad certificadora que soportará MTC. Es un paso importante, pero la autenticación post-quantum a escala sigue siendo un trabajo en progreso.

Qué ha cambiado en el lado de los orígenes

Cloudflare también publicó hace poco Automatic Key Exchange, una función que sondea cada servidor de origen, detecta qué algoritmos soporta y elige automáticamente el más fuerte disponible al establecer la conexión TLS 1.3. Los datos publicados por SDxCentral muestran el impacto:

Las conexiones diarias con post-quantum entre Cloudflare y orígenes pasaron de unos 25.000 millones a unos 45.000 millones durante el despliegue.
El porcentaje de conexiones PQ TLS 1.3 que completan en un único round-trip subió del 0% al 99,2%.
La latencia del percentil 90 del handshake mejoró en más de 150 milisegundos.
Cloudflare asigna preferencias de intercambio a más de un millón de dominios; un 33% ya van a X25519MLKEM768, un 64% se queda en X25519 clásico, y el resto usa otra curva soportada por su infraestructura.
En total, más del 12% de los orígenes individuales de la red de Cloudflare ya soportan intercambio post-quantum.

Si tu origen es legacy y no puede actualizarse, la salida que ofrece Cloudflare es ponerlo detrás de un Cloudflare Tunnel: el túnel negocia TLS 1.3 con X25519MLKEM768 contra la red de Cloudflare, así que el origen legacy "queda protegido" sin necesidad de tocarlo.

¿Qué significa esto para tu startup?

Aunque tu empresa no venda al gobierno de Estados Unidos, los plazos federales y de la Unión Europea están tirando del mercado. Las mismas librerías, routers, balanceadores y servicios que usan bancos y hospitales vienen de proveedores que están adaptando su stack para cumplir con la fecha de 2030 marcada por NIST y con los hitos del NCSC del Reino Unido (descubrimiento e inventario para 2028, migraciones prioritarias para 2031, cierre total para 2035). Cuando tu proveedor de CDN, tu proveedor de correo o tu balanceador migren, tú migras con ellos casi sin darte cuenta. El problema aparece cuando uno de esos componentes no está listo y bloquea la cadena.

Tres acciones concretas que puedes tomar esta semana:

Mide ya. Si tu dominio está detrás de Cloudflare, abre el dashboard de HTTP Traffic Analytics y revisa la tarjeta de TLS Key Exchange. Si no ves X25519MLKEM768, comprueba que TLS 1.3 esté encendido. Es un cambio de configuración, no un proyecto.
Audita qué datos atraviesan TLS. No es lo mismo proteger un blog público que un endpoint que sirve historiales clínicos, contratos legales o credenciales de larga vida. Aplica el principio del harvest now, decrypt later: si los datos de esa conexión siguen siendo sensibles en 2034, ese flujo necesita post-quantum ya.
Pregunta a tu proveedor de infraestructura por su roadmap. No te quedes en "sí, soporta post-quantum": pregunta qué algoritmos concretos, desde cuándo, y si su configuración por defecto permite hacer downgrade a algoritmos clásicos (lo cual sería un agujero equivalente al que dejó POODLE con SSLv3 en 2014). Esa pregunta separa marketing de ingeniería real.

Si construyes producto SaaS, una cuarta acción rentable es añadir a tu propia telemetría el campo que Cloudflare acaba de exponer: te servirá para detectar qué fracción de tus clientes empresariales está llegando con navegadores y clientes que todavía no hablan X25519MLKEM768, y avisarles antes de que el deadline regulatorio les pille con el stack sin migrar.

Conclusión

La criptografía post-quantum dejó de ser un tema de papers y pasó a ser un problema de producto. La nueva visibilidad por dominio de Cloudflare convierte una pregunta que antes requería a un equipo de criptógrafos en una métrica que cualquiera puede leer en su dashboard. La cifra de fondo es incómoda pero útil: la mayoría de tu tráfico web de navegadores probablemente ya viaja protegido, pero la mayoría de tus conexiones a orígenes sigue siendo clásica. Saber exactamente cuánto de cada cosa es el primer paso para cerrar esa brecha antes de que 2030 deje de ser una fecha lejana.