Más allá del sobrepeso poscuántico: estrategias de ingeniería para contener los handshakes TLS

En mi publicación anterior, analizamos cómo afecta al rendimiento el establecimiento de claves poscuántico. ¿La respuesta corta? El uso de CPU apenas cambia, pero el tamaño del handshake TLS aumenta considerablemente. Pasar del X25519 clásico al híbrido X25519MLKEM768 añade unos 1,2 KB al handshake TLS en la dirección crítica. Cuando inevitablemente sumemos firmas poscuánticas (como ML-DSA), las cadenas de certificados superarán con facilidad la ventana de congestión inicial de TCP (14,5 KB), lo que obligará a realizar viajes de ida y vuelta adicionales (RTT) e introducirá una latencia de red real.

La PKI web ya avanza hacia los Merkle Tree Certificates (MTC), diseñados principalmente para resolver este problema de las firmas poscuánticas muy largas. Sin embargo, no todos los sistemas podrán usar MTC, así que en esta publicación quería explorar qué más podemos hacer. Y lo cierto es que hay bastantes opciones.

Tenemos dos palancas de ingeniería principales: una es reducir el tamaño físico del handshake TLS y la otra es reducir la frecuencia con la que se produce un handshake completo.

A continuación, veremos de forma práctica cómo optimizar ambos aspectos y en qué punto se encuentra el sector en la estandarización de estas soluciones. Lo mejor es que te beneficiarás de estas optimizaciones desde hoy, incluso con criptografía tradicional (RSA y/o curva elíptica).

En lo que respecta al handshake TLS, tenemos varias opciones:

• Eliminar los certificados raíz de las cadenas: Uno de los errores de configuración más comunes es transmitir el certificado de la CA raíz junto con los certificados intermedios. Los clientes ya almacenan las raíces de confianza localmente; enviarlas por la red no cumple ninguna función y desperdicia un ancho de banda valioso.
• Implementar la compresión de certificados (RFC 8879): La RFC 8879 permite a los extremos negociar algoritmos de compresión estándar (Brotli, zlib o zstd) para los datos de los certificados. En la práctica, comprime las cadenas de certificados voluminosas entre un 30 % y un 50 %. Aunque el soporte está fragmentado en los navegadores modernos (Chrome admite Brotli; Firefox admite Brotli, zlib y zstd; y Safari admite zlib), OpenSSL admite los tres, por lo que esta técnica debería generar cierto ahorro. Por desgracia, la compresión solo funciona con el texto contenido en los certificados. Por diseño, las firmas y las claves públicas no se comprimen bien.
• Modernizar las claves públicas (ECC en lugar de RSA): Si aún no has abandonado los antiguos certificados RSA, hazlo. Pasar de RSA-2048 a ECDSA reduce de inmediato el tamaño de las claves públicas y las firmas, lo que se traduce en certificados más ligeros antes de que llegue la PQC.
• Claves públicas sin procesar (RFC 7250): Para la comunicación entre máquinas, las API o los entornos con recursos limitados en los que los extremos ya confían en la clave pública del servidor o la almacenan en caché por un canal independiente, la RFC 7250 permite omitir por completo la transmisión de las CA intermedias y los envoltorios de los certificados.

El IETF ha explorado otros mecanismos de compresión y reducción, aunque su adopción varía enormemente:

• TLS Cached Info (RFC 7924): Diseñado para que los clientes indiquen qué certificados tienen en caché y así evitar su retransmisión. Esta RFC se publicó en mayo de 2026, pero todavía no cuenta con un amplio soporte en bibliotecas y agentes de usuario. Quizá mejore su soporte a medida que empecemos a migrar a la criptografía poscuántica.
• Abridged Compression for WebPKI Certificates (draft-ietf-tls-cert-abridge): Utiliza diccionarios estáticos predistribuidos para comprimir las estructuras de los certificados. Aunque lo adoptó el TLS Working Group, desde entonces ha caducado y parece abandonado.

En TLS hay dos tipos de handshakes: completos y abreviados (reanudados). Estos últimos no transportan ningún certificado, lo que supone un ahorro considerable:

• Reanudación de sesión: La reanudación de sesión permite que los clientes recurrentes se autentiquen mediante una clave simétrica precompartida, sin pasar por el costoso intercambio de claves asimétrico ni por la transferencia de certificados.
• TLS 1.3 0-RTT (Early Data): Para los visitantes recurrentes, 0-RTT permite que los datos de la aplicación viajen en el primer envío de paquetes junto con el handshake de reanudación, lo que elimina por completo los retrasos de ida y vuelta del handshake. Esta técnica no ofrece un secreto perfecto hacia adelante (forward secrecy) completo y solo debe utilizarse cuando el primer envío del agente de usuario no contenga información sensible.

El handshake más rápido es el que nunca tienes que hacer. Eliminar los intercambios asimétricos evita la creciente penalización de tamaño de las claves poscuánticas.

• Ajustar los keep-alives: No dejes que las conexiones TCP o TLS inactivas se cierren antes de tiempo. Ampliar los tiempos de espera de keep-alive a nivel de aplicación y de TCP en los proxies perimetrales (por ejemplo, NGINX, HAProxy o Envoy) mantiene los sockets activos para el tráfico de clientes en ráfagas o secuencial.
• Implementar HTTP/2 y HTTP/3 (QUIC): Al multiplexar varias solicitudes HTTP sobre una única conexión subyacente, los protocolos modernos eliminan la costumbre derrochadora de abrir sesiones TLS paralelas para recursos alojados en el mismo origen.

Al optimizar el rendimiento de TLS, la conversación se centra casi siempre en el tráfico entrante (frontend), es decir, en cómo se conectan los clientes a tus servidores perimetrales. Pero en las arquitecturas modernas de microservicios, las redes empresariales y las aplicaciones nativas de la nube, el tráfico saliente (egress) supone una enorme penalización de latencia oculta.

Cada vez que un servicio interno inicia una llamada a una API externa, obtiene una dependencia de terceros o se comunica entre clústeres de varias regiones, desencadena un nuevo handshake TLS.

Cuando se suma la sobrecarga poscuántica a estas mallas de microservicios internas, la latencia acumulada crece rápidamente. Para mitigarlo en el lado saliente:

• Implementar proxies de reenvío con agrupación de conexiones: Colocar un proxy de reenvío saliente (o un sidecar de service mesh como Envoy) entre tus microservicios internos y los extremos externos permite consolidar y agrupar las conexiones. En lugar de que cada hilo efímero de la aplicación inicie su propio handshake TLS poscuántico con un extremo externo, el proxy de reenvío mantiene un grupo de conexiones TLS persistentes y de larga duración.
• Keep-alives y reanudación en el tráfico saliente: Al igual que con los proxies frontend, ajustar a fondo la reanudación de sesión y la configuración de keep-alive en la infraestructura de proxy saliente garantiza que las aplicaciones internas se beneficien de conexiones ya activas y de baja latencia.

Al optimizar tanto la entrega frontend como la infraestructura saliente, proteges a tus usuarios finales y tu arquitectura interna de la inevitable inflación de bytes de la criptografía poscuántica.