El primer paso poscuántico que su CDN no puede dar por usted

Un ingeniero que abra la página de estado poscuántico de Cloudflare lleva tres años leyendo buenas noticias sin hacer nada. En el tramo entre el navegador de un visitante y el borde de Cloudflare, el cifrado poscuántico está activo por defecto desde 2023, con el acuerdo de claves híbrido que hoy se escribe X25519MLKEM768, y ningún cliente lo configuró. Llegó como llega el tiempo atmosférico.

El 29 de julio esa forma de trabajar se acabó. Cloudflare anunció la autenticación poscuántica en el otro tramo, entre su red y los servidores de origen que gestionan sus clientes, con firmas ML-DSA. La autenticación no es algo que un proxy pueda hacer en su nombre, porque lo que se acredita es su servidor. Para usarla, ese servidor tiene que guardar y presentar un certificado firmado con un algoritmo que probablemente nunca ha visto.

Qué se ha entregado realmente

Dos productos llevan el cambio. Authenticated Origin Pulls es el mecanismo por el que Cloudflare presenta un certificado de cliente a su origen, de modo que el origen pueda rechazar conexiones que no hayan pasado por Cloudflare, y ahora acepta ML-DSA en los niveles de configuración por zona y por nombre de host. El nivel global figura como pendiente. El Custom Origin Trust Store, que permite a un cliente subir sus propias autoridades de certificación en lugar de depender del conjunto público, admite ahora autoridades que firman con ML-DSA, de modo que un certificado de origen puede validarse contra un firmante poscuántico.

Se admiten los tres conjuntos de parámetros de FIPS 204: ML-DSA-44, ML-DSA-65 y ML-DSA-87. El acuerdo de claves de la conexión sigue siendo el híbrido X25519MLKEM768. Dicho de otro modo, la confidencialidad de ese tramo ya estaba resuelta; lo que ha cambiado es la parte que demuestra quién está en cada extremo.

Cinco cosas que deben cambiar en una máquina suya

La lista de requisitos es corta y cada punto cae de su lado de la conexión. Necesita OpenSSL 3.5.0 o posterior en el origen para poder generar siquiera una cadena de certificados ML-DSA. El certificado hay que subirlo en la codificación de solo semilla que define FIPS 204, que no es la que la mayoría de las herramientas produce por costumbre. El servidor web del origen, NGINX en el propio ejemplo de Cloudflare, debe configurarse para presentar el certificado ML-DSA o para verificar el certificado de cliente contra él. Si usa el Custom Origin Trust Store, el modo SSL/TLS de la zona debe estar en Full (strict). Y después hay que retirar la confianza en el mecanismo vulnerable a la computación cuántica, porque dejarlo permite a un atacante negociar el camino antiguo y convierte el nuevo en algo decorativo.

Nada de esto es exótico. OpenSSL 3.5.0 salió el 8 de abril de 2025 como línea de soporte prolongado con actualizaciones hasta abril de 2030, y fue la primera versión que incorporó de forma nativa los tres estándares poscuánticos del NIST. La dificultad no está en el número de versión. Está en que el origen suele ser la máquina menos visitada de todo el parque: un aparato, una caja gestionada por un proveedor, una máquina virtual que nadie ha vuelto a construir desde que se aprovisionó, o un balanceador cuya pila TLS es problema de otro hasta que deja de serlo.

El propio despliegue de Cloudflare es el argumento a favor de una fase de pruebas. El 10 de junio de 2026 tuvo una incidencia en producción durante esta implantación, provocada por la comprobación del campo KeyUsage en los certificados. Es un detalle de una extensión de certificado, y golpeó a un equipo que se gana la vida construyendo bibliotecas TLS, sobre una infraestructura que controla de extremo a extremo. Una empresa mediana que haga el mismo cambio un jueves por la tarde debería contar con encontrar algo parecido.

Por qué el conjunto recomendado es el más pequeño

Cloudflare recomienda ML-DSA-44 para la mayoría de las aplicaciones y lo describe como la opción más eficiente. Es una decisión técnica defendible y es a la vez el menor de los tres conjuntos de FIPS 204, situado en la categoría de seguridad 2 del NIST. La recomendación por defecto más habitual en otros sitios es ML-DSA-65, categoría 3. Las firmas poscuánticas son grandes frente a las que sustituyen y, en un tramo que transporta todas y cada una de las peticiones entre el borde y el origen, la diferencia de tamaño es un coste real de latencia y ancho de banda, no uno teórico.

Lo que importa a un propietario es que aquí aparece una decisión con su nombre. Si su política de seguridad o su auditor ya se han fijado en la categoría 3 para firmar, adoptar en silencio la recomendación del CDN crea una excepción que tendrá que explicar. Deje por escrito el conjunto de parámetros, con el motivo, antes de que otro descubra la discrepancia en una revisión.

El plazo que es real y el que no lo es

Conviene ser claro con la urgencia, porque las dos mitades de lo poscuántico corren con relojes distintos de verdad. El tráfico cifrado que se graba hoy puede descifrarlo una máquina futura, y eso es lo que convierte el acuerdo de claves en un problema del presente. Una firma no se falsifica hacia atrás del mismo modo: nadie usará un ordenador cuántico en 2032 para inventar de forma retroactiva un saludo criptográfico de esta mañana. La razón para empezar ahora no es que le estén atacando, sino la longitud de la cola que hay detrás del cambio, que pasa por autoridades de certificación, hardware, aparatos de proveedores y todos los orígenes que había olvidado.

Cloudflare ha puesto fechas a su propia cola: seguridad poscuántica completa en todos sus productos para 2029 y un primer despliegue de Merkle Tree Certificates del lado del visitante previsto para 2027. Esos son sus plazos, no los de usted. El suyo es la próxima auditoría que pregunte qué protege la conexión entre su CDN y sus servidores, y en España es el Centro Criptológico Nacional el que marca la referencia. La respuesta honesta hoy, para casi todos, es criptografía clásica con un sustituto disponible y sin usar.