TLS poscuántico híbrido en un ingress de Kubernetes

En un clúster de Kubernetes, el TLS poscuántico híbrido se configura allí donde el handshake termina realmente, casi nunca en el contenedor de la aplicación. Ese punto suele ser el pod del controlador de ingress, un balanceador de carga en la nube situado delante o un sidecar de service mesh. El trabajo consta de cuatro pasos: encontrar el punto real de terminación, comprobar la versión de la biblioteca TLS que se ejecuta allí, colocar un grupo híbrido como X25519MLKEM768 por delante de un grupo clásico en la lista de preferencias y, por último, verificar desde fuera del clúster.

Paso 1: encontrar dónde termina realmente el handshake

Los equipos configuran a menudo el componente equivocado y concluyen que su controlador no admite el intercambio de claves poscuántico. Trace primero el recorrido de un paquete del cliente. Solo el componente que posee la clave privada y envía el ServerHello decide el grupo de intercambio de claves.

Confirme la topología con comandos de solo lectura antes de modificar nada:

kubectl get ingress -A -o wide
kubectl -n ingress-nginx get svc -o wide
kubectl -n ingress-nginx get svc ingress-nginx-controller -o jsonpath='{.metadata.annotations}'

Las anotaciones del balanceador de carga en el Service del controlador indican si la capa de la nube termina TLS o lo deja pasar. Si lo termina, ningún ajuste del ingress cambiará el grupo negociado.

Paso 2: comprobar qué admite la biblioteca TLS del controlador

Los grupos híbridos son una propiedad de la pila TLS compilada en la imagen del controlador, no de Kubernetes. Para las compilaciones basadas en OpenSSL, se requiere OpenSSL 3.5 o posterior para los grupos ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, mecanismo de encapsulación de claves basado en retículos modulares). Los planos de datos basados en BoringSSL, como Envoy, utilizan su propia nomenclatura de grupos y su propia matriz de compatibilidad, así que consulte las notas de la versión exacta que ejecuta.

kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- openssl version

Si esa versión es anterior a la 3.5, deténgase aquí y planifique una actualización del controlador. Ninguna clave de configuración puede habilitar un grupo que la biblioteca no implementa.

Los nombres de grupo y los codepoints IANA que puede utilizar legítimamente están publicados en el registro de parámetros TLS (iana.org):

• X25519MLKEM768 (0x11EC, 4588), el valor predeterminado de facto en los navegadores actuales, descrito en nuestra página sobre X25519MLKEM768.
• SecP256r1MLKEM768 (0x11EB, 4587) y SecP384r1MLKEM1024 (0x11ED, 4589), para entornos que exigen curvas NIST.
• Los grupos ML-KEM puros MLKEM512, MLKEM768 y MLKEM1024 (512, 513, 514). No son híbridos: la mayoría de los lectores no debería desplegarlos todavía en el borde público.

El acuerdo de claves híbrido para TLS 1.3 se especifica en el RFC 10024 (rfc-editor.org). ML-KEM en sí es FIPS 203, definitivo desde el 13 de agosto de 2024 (csrc.nist.gov). El grupo preestándar del borrador de Kyber X25519Kyber768Draft00 (0x6399) está obsoleto: si aparece en cualquier parte de su configuración, elimínelo.

Paso 3: configurar los grupos, con un respaldo clásico

Solo se negocia un grupo de intercambio de claves por conexión, y el servidor elige entre los que ofreció el cliente. Por tanto, colocar un grupo híbrido en primer lugar y un grupo clásico a continuación es seguro por diseño: los clientes que conocen el grupo híbrido lo utilizan y los clientes más antiguos recurren a X25519 o P-256.

ingress-nginx

El controlador expone la clave de ConfigMap ssl-ecdh-curve, que se corresponde con la directiva de nginx ssl_ecdh_curve y se transmite a la biblioteca TLS como una lista ordenada de grupos (su valor predeterminado es auto). Confirme la clave en la referencia del ConfigMap para la versión del controlador que ejecuta y, a continuación, aplique:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  ssl-protocols: "TLSv1.3 TLSv1.2"
  ssl-ecdh-curve: "X25519MLKEM768:X25519:prime256v1"

Aquí prime256v1 es el nombre que OpenSSL da a secp256r1. Mantener dos grupos clásicos después del híbrido preserva a los clientes TLS 1.2 y a cualquier cliente TLS 1.3 que no implemente ML-KEM. La misma lógica de ordenación se aplica a un servidor web independiente, tal como se describe en nuestra guía para habilitar ML-KEM en nginx, Apache, HAProxy y Caddy.

Otros controladores y service meshes

No copie anotaciones de un controlador a otro. Una anotación que el controlador no reconoce se ignora sin aviso, y ese es el modo de fallo más peligroso en este caso: el despliegue parece correcto y nada ha cambiado. El principio es idéntico en todas partes; lo que cambia es la interfaz:

• Los planos de datos basados en Envoy exponen parámetros TLS que incluyen una lista de curvas ECDH. En una malla, a ese campo se suele acceder mediante un mecanismo de parcheo avanzado y no a través de una API de primer nivel, así que consulte la documentación de su malla y de su versión de proxy.
• Los controladores basados en HAProxy y Traefik definen la lista de grupos en sus propios objetos de configuración. Busque la clave exacta en la documentación del controlador para su versión y valídela en preproducción.
• Si un balanceador de carga gestionado termina TLS, su única palanca es la política TLS del proveedor. Cuando no se ofrece ninguna política híbrida, la alternativa es trasladar la terminación al clúster detrás de un servicio passthrough de capa 4, lo que constituye un cambio de arquitectura y merece su propia revisión.

No toque por ahora la cadena de certificados

El tráfico grabado solo está protegido por el intercambio de claves, y esa es precisamente la esencia de «cosechar ahora, descifrar después»: un atacante que almacena hoy el texto cifrado puede descifrarlo más adelante si el intercambio de claves era clásico. Nuestro artículo sobre cosechar ahora, descifrar después (harvest now, decrypt later) explica por qué el intercambio de claves va primero en la cola. Los certificados pueden migrar más tarde: las autoridades de certificación públicas siguen emitiendo certificados ECDSA y RSA, y las firmas ML-DSA, estandarizadas como FIPS 204, aún no están disponibles de forma general en las cadenas TLS públicas. Mantenga sin cambios su emisor actual de cert-manager en esta fase.

Paso 4: verificar desde fuera del clúster

Realice la prueba desde una máquina en Internet, por el mismo recorrido que sigue un navegador. Nunca verifique con kubectl port-forward: omite el balanceador de carga y el borde, por lo que puede mostrar un handshake híbrido que ningún cliente real obtendrá jamás. Con OpenSSL 3.5 o posterior:

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Un resultado correcto muestra el grupo negociado. A continuación, compruebe que el respaldo sigue funcionando, que es la prueba que los equipos olvidan:

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Repita ambas pruebas para cada nombre de host público, incluido el dominio raíz y cualquier host servido por una segunda clase de ingress o por otro proveedor de borde. Un clúster con dos clases de ingress suele acabar migrado a medias. Lo que una prueba externa puede y no puede mostrar se describe en nuestra metodología del escáner.

Paso 5: desplegar y conservar las evidencias

1. Aplique primero el cambio en preproducción, en un controlador que ejecute la misma etiqueta de imagen que producción.
2. Promuévalo a un único nombre de host de producción o a una clase de ingress canary, no a toda la flota.
3. Vigile los errores de handshake TLS y el uso de CPU del controlador durante al menos un ciclo de actividad completo. Las key shares de ML-KEM son más grandes que una share X25519, por lo que los mensajes ClientHello y ServerHello aumentan de tamaño.
4. Tenga preparada la reversión: restaurar el valor anterior de la clave del ConfigMap recupera el comportamiento previo en la siguiente recarga.
5. Registre el resultado en su inventario criptográfico, con la fecha y el host probado.

Este último paso es el que convierte un cambio de plataforma en evidencia de cumplimiento. La correspondencia siguiente es nuestra interpretación de cómo el artefacto técnico responde al requisito, no una cita de los textos. Se trata de información, no de asesoramiento jurídico.

Siguiente paso

Una vez aplicado el ConfigMap y superadas las pruebas en preproducción, confirme el resultado visible desde el exterior: analice su dominio con PQC Status para ver qué grupo de intercambio de claves negocia realmente su ingress, qué versiones de TLS ofrece y cómo es la cadena de certificados. Ejecute el análisis una vez por cada nombre de host público, antes y después de cada actualización de la imagen del controlador, porque un cambio de imagen puede devolverle sin aviso a un grupo clásico. Un análisis describe únicamente la configuración TLS visible desde el exterior: no es una certificación ni una atestación de cumplimiento.