Guía de implementación de TLS 1.3 post-cuántico: X25519MLKEM768

Respuesta rápida: X25519ML-KEM-768 es un grupo de intercambio de claves híbrido utilizado con TLS 1.3 , que combina el clásico X25519 con ML-KEM-768. Ya se negocia por defecto en las versiones actuales de Chrome, Edge y Firefox, y las principales CDN lo prefieren automáticamente cuando ambos extremos lo admiten. La implementación es principalmente un ejercicio de configuración en pilas modernas (OpenSSL 3.5+, versiones actuales de NGINX y HAProxy), pero aumenta el tamaño del TLS ClientHello de aproximadamente 300 a 500 bytes a aproximadamente 1,300 a 1,500 bytes, lo que expone a los dispositivos intermedios que no pueden analizar un grupo TLS desconocido. Esta guía cubre la mecánica de negociación de TLS 1.3, los riesgos de compatibilidad, la configuración del grupo de cifrado y cómo realizar pruebas antes de la implementación generalizada.

X25519MLKEM768 es, con mucha diferencia, el protocolo de criptografía postcuántica más utilizado en internet actualmente. Los navegadores lo incluyen por defecto, las CDN lo prefieren automáticamente y, para la mayoría de las conexiones, es completamente invisible. El trabajo de implementación restante se centra principalmente en las excepciones: el dispositivo intermedio que no puede analizar un ClientHello más extenso, la versión anterior que ignora silenciosamente el nombre del grupo y el segmento de red donde falla la inspección TLS. Esta guía explica qué configurar, qué probar y qué suele fallar.

Puntos Clave

• X25519MLKEM768 ya se negocia de forma predeterminada en las versiones actuales de Chrome, Edge y Firefox, y las principales CDN lo prefieren automáticamente cuando ambos puntos finales lo admiten.
• El ClientHello híbrido aumenta su tamaño de aproximadamente 300 a 500 bytes a aproximadamente 1,300 a 1,500 bytes, lo que aún permite que quepa en un único segmento TCP para la mayoría de las conexiones, pero es lo suficientemente grande como para exponer dispositivos intermedios con suposiciones de tamaño o ID de grupo codificadas.
• El modo de fallo de producción más común es que un dispositivo de inspección TLS rechace directamente un punto de código de grupo no reconocido en lugar de ignorarlo.
• La solución alternativa de Chrome para entornos empresariales, la política PostQuantumKeyAgreementEnabled, siempre estuvo pensada para ser temporal y se está eliminando gradualmente hasta 2026, por lo que tratarla como una solución de compatibilidad a largo plazo es un error.
• En casi todas las conexiones, la sobrecarga es invisible; la excepción son las conexiones TLS de alta frecuencia y corta duración, donde el coste del protocolo de enlace ya es un factor a tener en cuenta.

Mecánicas de negociación

X25519MLKEM768 es un grupo TLS 1.3 con nombre, estandarizado por el grupo de trabajo TLS de la IETF, que concatena los resultados de un intercambio X25519 clásico y una encapsulación ML-KEM-768 en un único secreto compartido híbrido. Un cliente compatible lo anuncia en la extensión supported_groups del ClientHello junto con sus grupos clásicos; un servidor compatible, si prefiere el grupo híbrido, responde con una clave compartida en ese grupo, y el handshake resultante produce un secreto compartido que requiere romper tanto X25519 como ML-KEM-768 para recuperarse. Los clientes y servidores que no admiten el grupo simplemente no lo ofrecen ni lo seleccionan, negociando en su lugar un grupo clásico compatible entre sí, por lo que la negociación en sí se degrada de forma gradual por diseño.

Descubra cómo HSM-as-a-Service admite la gestión de claves ML-KEM para la terminación TLS sin necesidad de un ciclo de adquisición de hardware.

Compatibilidad entre cliente y servidor

La compatibilidad del lado del cliente ya es amplia: las versiones actuales de Chrome, Edge y Firefox negocian X25519MLKEM768 de forma predeterminada. Más de un tercio del tráfico generado por humanos hacia las principales redes CDN ahora utiliza el acuerdo de clave post-cuántico híbrido, lo que significa que la mayoría de los servidores de origen ya reciben ClientHellos con capacidad híbrida, independientemente de si el propio origen admite o no el grupo.

La compatibilidad del lado del servidor depende de la versión de la biblioteca TLS. OpenSSL 3.5 y posteriores admiten el grupo de forma nativa; las compilaciones de NGINX y HAProxy compiladas contra un sistema OpenSSL más antiguo ignorarán silenciosamente los nombres de grupo que no reconozcan en directivas de configuración como ssl_ecdh_curve, que es una fuente común de confusión del tipo "¿por qué no funciona esto?", la configuración se aplica sin errores pero no tiene ningún efecto.

Configuración del grupo de cifrado

Configurar la compatibilidad con X25519MLKEM768 en plataformas modernas es un cambio en la lista de grupos, no una recompilación, siempre que la biblioteca TLS subyacente ya la admita. La lista de verificación práctica:

• Antes de cambiar la configuración, confirme que la versión de la biblioteca TLS admite el grupo de forma nativa; OpenSSL 3.5 o posterior es la versión básica recomendada.
• Agregue X25519MLKEM768 a la lista de preferencias de grupo del servidor, normalmente con prioridad sobre los grupos que solo admiten comandos clásicos, para que se le dé preferencia cuando un cliente lo ofrezca.
• Conserve los grupos clásicos en la lista en lugar de eliminarlos; el grupo híbrido debe ser una adición, no un reemplazo, ya que no todos los clientes lo admiten todavía.
• Verifique el grupo negociado en la salida del protocolo de enlace después de la configuración, en lugar de asumir que la directiva de configuración surtió efecto automáticamente.

Riesgos de los dispositivos intermedios: dónde fallan realmente las implementaciones

El problema más común en entornos de producción es que un dispositivo de inspección TLS, un firewall de última generación, un proxy DLP o un descargador SSL no reconoce el punto de código de grupo X25519MLKEM768 y rechaza directamente el ClientHello en lugar de ignorar el grupo desconocido y utilizar uno clásico. El fallo suele manifestarse como errores de protocolo de enlace registrados como "grupo desconocido" o "extensión no compatible", mientras que las conexiones con el mismo dispositivo de inspección se establecen correctamente cuando solo se ofrecen grupos clásicos.

Los propios datos de implementación de Chrome confirman que se trata de un riesgo real, no teórico: el equipo trabajó individualmente con varios proveedores, incluidos proveedores de infraestructura y procesadores de pagos, para solucionar las incompatibilidades detectadas durante una implementación gradual y por fases antes de alcanzar la disponibilidad general. La solución para un segmento de red afectado consiste en configurar un receptor exclusivamente clásico para esa ruta o bien reubicar el punto de terminación TLS para que el segmento analizado siga siendo clásico, mientras que el segmento de origen al balanceador de carga utilice el grupo híbrido.

Pruebas de tráfico y observabilidad

Antes de la implementación generalizada, planifique el cambio y supervise dos señales específicas: la fracción de conexiones que negocian con éxito X25519MLKEM768 frente a la que vuelve al protocolo clásico, y cualquier aumento repentino en los fallos de handshake correlacionado con la implementación. Una métrica que rastrea el grupo negociado por nombre, y no solo la tasa general de éxito del handshake, hace que la interferencia del middlebox sea visible rápidamente en lugar de aparecer como un aumento vago en los errores de conexión genéricos. Pruebe con su ruta de red real, incluyendo cualquier dispositivo de inspección TLS, balanceadores de carga y configuración de CDN en la cadena, y no solo una prueba de laboratorio directa del cliente al origen, ya que los modos de fallo mencionados anteriormente están específicamente relacionados con el middlebox y no aparecerán en una configuración de prueba simplificada.

Retroceso: ¿Por qué se cierra la escotilla de escape de la Enterprise?

Chrome implementó una política empresarial, PostQuantumKeyAgreementEnabled, específicamente para que los administradores pudieran deshabilitar el acuerdo de clave híbrida mientras su proveedor de middleware implementaba una solución de compatibilidad. Esta política siempre se concibió como una solución temporal, no como una opción de configuración permanente, y Google ha estado eliminando gradualmente su efecto: a partir de Chrome 138 a mediados de 2025, deshabilitar la política ya no desactiva la negociación ML-KEM, y la eliminación completa de la anulación está programada para 2026. Cualquier plan de reversión basado en esta política empresarial necesita una fecha límite real. La solución definitiva consiste en actualizar el middleware afectado para que analice correctamente el ClientHello más extenso, en lugar de depender indefinidamente de una solución temporal que se está cerrando.

Impacto en el rendimiento: Mayormente invisible, con una excepción.

Para la gran mayoría de las conexiones, el aumento de tamaño, aproximadamente de 1,300 a 1,500 bytes en comparación con los 300 a 500 bytes del ClientHello, aún cabe en un único segmento TCP y no tiene un efecto apreciable en la experiencia del usuario. Las conexiones HTTP/2 o HTTP/3 de alto volumen con keep-alive persistente no se ven afectadas, ya que el handshake se produce una sola vez por conexión, independientemente del grupo utilizado. El único escenario en el que vale la pena medir directamente el coste adicional del handshake son las conexiones TLS de alta frecuencia y corta duración, donde la sobrecarga del handshake ya representaba una fracción significativa del coste total de la conexión antes de que se añadiera el grupo híbrido.

Lo que realmente recomendamos

Habilite X25519MLKEM768 como una adición a su lista de grupos existente, no como un reemplazo, en cualquier servidor que ejecute OpenSSL 3.5 o posterior. Realice pruebas con su ruta de red real, incluidos los dispositivos de inspección, antes de una implementación generalizada, e integre la telemetría del grupo negociado para que un problema con el dispositivo intermedio se manifieste como una métrica en lugar de un ticket de soporte. Si actualmente depende de una anulación de política empresarial, considérelo como un temporizador de cuenta regresiva vinculado al cronograma de eliminación gradual de Google, no como una solución permanente, y priorice la actualización del dispositivo subyacente.

Cómo puede ayudar la consultoría de cifrado

Para que el intercambio de claves híbrido funcione correctamente, es fundamental que el HSM y la capa de gestión de claves que se encuentran detrás de los puntos de terminación TLS admitan ML-KEM de forma nativa, que es precisamente lo que ofrece HSM como servicio : gestión de claves validada por FIPS y compatible con ML-KEM, de modo que su pila TLS pueda adoptar X25519MLKEM768 sin un ciclo de adquisición de hardware independiente para cada entorno que ejecute la implementación.

Nuestros servicios de asesoramiento de PQC elaboran el plan de implementación por etapas y de telemetría que se describe en esta guía, secuenciando la implementación del intercambio de claves híbrido en función de los riesgos específicos de los sistemas intermedios y heredados en su red.

Un cambio de configuración con una cola de compatibilidad

La implementación de X25519MLKEM768 es, en su mayor parte, un problema resuelto a nivel de cliente y CDN; el trabajo restante consiste en encontrar y corregir los middlewares y stacks heredados específicos en su propia red que nunca se probaron con un ClientHello más grande. Realice pruebas con la ruta de red real, supervise la telemetría del grupo negociado en lugar de las tasas de éxito del handshake genérico y trate cualquier anulación empresarial como un puente temporal con una ventana de cierre, no como una estrategia de compatibilidad. Las organizaciones que aún dependen de la opción clásica de reserva en 2026 son, en su mayoría, las que aún no han encontrado y corregido su único dispositivo incompatible.

Preguntas frecuentes

¿Necesito eliminar los grupos de intercambio de claves clásicos al habilitar X25519MLKEM768?

No. Añádalo a la lista de grupos existente en lugar de reemplazar los grupos clásicos. Los clientes que no admiten el grupo híbrido negociarán un grupo clásico, y eliminar por completo la compatibilidad con el grupo clásico rompería la compatibilidad con los clientes que aún no han adoptado el intercambio de claves híbrido.

¿Cuál es la causa más común de los fallos de protocolo de enlace X25519MLKEM768?

Un dispositivo de inspección TLS o un middleware que no reconoce el punto de código del grupo y rechaza directamente el ClientHello, en lugar de ignorar el grupo desconocido y continuar, se manifiesta como errores de "grupo desconocido" o "extensión no compatible" específicos de la ruta de red inspeccionada.

¿Cuánto afecta realmente al rendimiento el mensaje ClientHello de mayor tamaño?

En casi todas las conexiones, la diferencia no es cuantificable. El mensaje ClientHello crece hasta alcanzar aproximadamente entre 1,300 y 1,500 bytes, pero aún así cabe en un único segmento TCP, y las conexiones persistentes amortizan el coste del protocolo de enlace único. Las conexiones de alta frecuencia y corta duración son el único caso que merece la pena medir directamente.

¿Podemos confiar en la política PostQuantumKeyAgreementEnabled de Chrome como una solución a largo plazo para la incompatibilidad de dispositivos intermedios?

No. Se diseñó como una solución temporal mientras los proveedores de dispositivos intermedios actualizaban sus productos, y Google ha estado eliminando gradualmente su efecto desde Chrome 138 a mediados de 2025, con la eliminación completa prevista para 2026. La solución definitiva consiste en actualizar el dispositivo incompatible, en lugar de depender de la anulación indefinidamente.

¿Mi servidor necesita OpenSSL 3.5 para ser compatible con X25519MLKEM768?

OpenSSL 3.5 es la base práctica para la compatibilidad nativa. Los servidores como NGINX o HAProxy, compilados con una versión anterior de OpenSSL, ignorarán silenciosamente el nombre del grupo en la configuración sin generar ningún error, lo cual es una causa común de configuraciones que parecen correctas pero que no tienen ningún efecto.