En 2011, la herramienta THC-SSL-DOS demostró que un solo portátil podía derribar servidores HTTPS de grandes organizaciones. El mecanismo no era volumétrico: el atacante explotaba la renegociación de sesión TLS para forzar al servidor a ejecutar operaciones criptográficas asimétricas repetidamente en una única conexión TCP persistente. El coste computacional de esas operaciones es estructuralmente mayor en el servidor que en el cliente, porque el servidor realiza exponenciación modular con clave privada extensa (en el caso de RSA) o genera firmas ECDSA/Ed25519 (en TLS 1.3) para probar su identidad en cada handshake.
El agotamiento de handshake TLS/SSL es una categoría de ataque DDoS que explota esta asimetría de coste. En lugar de generar volumen de red, el atacante maximiza el consumo de CPU del servidor forzando el procesamiento repetido de handshakes TLS — ya sea mediante renegociación en una única conexión, o abriendo un gran número de conexiones nuevas.
La asimetría matemática de coste
El handshake TLS está compuesto por operaciones criptográficas con perfiles de coste radicalmente diferentes:
Operaciones baratas (simétricas, ejecutadas por hardware dedicado): tras el handshake, la transmisión de datos usa AES-GCM con soporte a instrucciones AES-NI. El coste marginal por byte es negligible.
Operaciones costosas (asimétricas, ejecutadas por software o aceleradoras especializadas):
- En protocolos hasta TLS 1.2 con RSA: el servidor realiza exponenciación modular con el exponente privado d, típicamente de 1024, 2048 o 4096 bits. La complejidad computacional crece con el cuadrado del tamaño de la clave. Una operación RSA-2048 requiere cientos de multiplicaciones modulares de precisión arbitraria — algo que el atacante no necesita ejecutar, ya que el cifrado RSA con la clave pública es órdenes de magnitud más rápido.
- En TLS 1.3 con ECDHE: el servidor realiza multiplicación escalar en curva elíptica para generar el par de claves Diffie-Hellman efémero y, a continuación, genera una firma ECDSA o Ed25519 para autenticar el key share. El cliente solo verifica esa firma — una operación significativamente más barata que generarla.
En benchmarks con openssl speed, la diferencia entre el cifrado simétrico y las operaciones de firma asimétrica abarca varios órdenes de magnitud. Adam Langley documentó en 2010 que Gmail procesaba handshakes SSL con menos del 1% de overhead adicional de CPU tras las optimizaciones — lo que demuestra que el coste bruto del handshake, sin esas optimizaciones, es el verdadero cuello de botella.
La asimetría es estructural: el cliente valida al servidor, pero el servidor hace el trabajo pesado de probar su identidad.
Vectores de ataque
THC-SSL-DOS — renegociación en una conexión única
THC-SSL-DOS no abre y cierra múltiples conexiones TCP. Su mecanismo es diferente y más eficiente para el atacante:
- El atacante establece una única conexión TCP persistente con el servidor.
- Completa el handshake TLS inicial normalmente — el servidor procesa un handshake completo.
- Inmediatamente envía un nuevo ClientHello de renegociación en la misma conexión, solicitando la renegociación de los parámetros TLS.
- El servidor, obligado por el protocolo, ejecuta un nuevo handshake completo sobre la misma sesión TCP.
- El atacante repite el paso 3 cientos de veces por segundo en la misma conexión.
El resultado es que una única conexión TCP fuerza N handshakes criptográficos completos en el servidor, sin ningún coste adicional de conexión TCP para el atacante. El RFC 5746 (Renegotiation Indication Extension) mitigó la dimensión de inyección de datos del ataque, pero no eliminó el coste de CPU de la renegociación en sí — hasta que TLS 1.3 eliminó la funcionalidad por completo.
TLS Handshake Flood — múltiples conexiones TCP
Este vector es distinto del THC-SSL-DOS y opera de la forma que intuitivamente parece “el ataque obvio”:
- El atacante abre simultáneamente un gran número de conexiones TCP nuevas.
- Inicia el handshake TLS en cada una de ellas.
- Puede completar el handshake y cerrar inmediatamente, o abandonarlo antes de su conclusión.
- Repite continuamente para mantener la presión sobre el servidor.
La diferencia clave respecto al THC-SSL-DOS: cada handshake consume un socket y una conexión TCP distinta. El TLS Handshake Flood está limitado por el overhead de establecimiento de conexiones TCP y por los límites de file descriptors del sistema operativo, lo que lo hace más costoso para el atacante por handshake inducido en el servidor.
TLS Session Ticket Flood y el riesgo de las STEKs
Los Session Tickets permiten al cliente reanudar una sesión TLS sin handshake completo, presentando un ticket cifrado por la STEK (Session Ticket Encryption Key) del servidor. Un atacante puede explotar este mecanismo de dos formas:
La primera consiste en enviar session tickets inválidos o fabricados en masa. El servidor debe intentar descifrar cada ticket con su STEK antes de poder confirmar que es inválido — una operación AES-CBC o AES-GCM con coste no negligible por ticket.
La segunda, más sofisticada, surge cuando la STEK está comprometida o es débil. Si el atacante obtiene la STEK (por ejemplo, en implementaciones que usan la misma clave durante períodos extensos sin rotación), puede fabricar tickets válidos que fuercen al servidor a procesar resumptions maliciosas a escala. El RFC 8446 recomienda rotación frecuente de STEKs y el uso de STEKs por instancia para limitar el impacto de un compromiso.
Ataque por degradación de cipher suite
El atacante negocia deliberadamente cipher suites con operaciones asimétricas más costosas — como RSA 4096 bits en lugar de ECDSA P-256 — maximizando el coste de CPU por handshake en el servidor. Este vector es complementario al TLS Handshake Flood: un número menor de conexiones simultáneas puede ser suficiente para saturar la CPU si cada handshake es artificialmente caro.
Encrypted Client Hello (ECH) y nuevos desafíos
El Encrypted Client Hello (ECH), extensión de TLS 1.3, cifra el ClientHello interno — incluyendo el Server Name Indication (SNI) — usando una clave pública del servidor distribuida vía DNS (registros HTTPS/SVCB). ECH mejora la privacidad del usuario, pero introduce un nuevo vector de agotamiento: el servidor debe intentar descapsular el ClientHello externo con su clave privada ECH antes de determinar si el cliente es legítimo. Un atacante que envíe ClientHellos ECH fabricados fuerza al servidor a ejecutar operaciones de descapsulamiento HPKE (Hybrid Public Key Encryption) en masa — un coste computacionalmente no trivial que no existía antes de ECH.
La mitigación principal es el rate limiting por IP de origen antes del procesamiento ECH, y el monitoreo de fallos de descapsulamiento como señal de ataque.
Perfil de coste y superficie de ataque por versión TLS
| Protocolo | RTTs | Operación asimétrica del servidor | Renegociación | Superficie de agotamiento |
|---|---|---|---|---|
| SSL 3.0 / TLS 1.0 | 2 | RSA: exponenciación modular con clave privada | Sí (vulnerable) | Alta — RSA lento + renegociación sin restricciones |
| TLS 1.2 | 2 | RSA o ECDHE + firma RSA/ECDSA | Sí (mitigado por RFC 5746) | Media — depende del cipher suite |
| TLS 1.3 | 1 | ECDHE + firma ECDSA/Ed25519 obligatoria | No (eliminada) | Reducida — sin renegociación, ECDHE eficiente |
| TLS 1.3 + ECH | 1 | ECDHE + ECDSA + descapsulamiento HPKE | No | Nueva superficie vía ClientHello fabricado |
Aceleración en hardware y métricas HPS
La resistencia de un servidor a los ataques de agotamiento TLS depende directamente de su capacidad de procesamiento criptográfico, medida en HPS (Handshakes Per Second):
Instrucciones AES-NI (disponibles en procesadores Intel y AMD desde 2010): aceleran las operaciones AES-GCM usadas en la transmisión de datos post-handshake y en la derivación de claves de sesión. No reducen el coste de las operaciones asimétricas del propio handshake.
Soporte de hardware para curvas elípticas (instrucciones MULX/ADCX/ADOX en Intel Broadwell+): aceleran la multiplicación escalar utilizada en ECDHE y ECDSA, reduciendo el coste de las operaciones más costosas del handshake TLS 1.3.
Intel QuickAssist Technology (QAT): co-procesador dedicado a operaciones criptográficas asimétricas incluyendo RSA, ECDSA y operaciones de clave pública.
El openssl speed permite medir el HPS real de un servidor ejecutando openssl speed ecdsa ecdhx25519 rsa2048 para comparar el throughput por algoritmo. En general, ECDSA P-256 y X25519 (Curve25519) ofrecen un HPS muy superior a RSA 2048 en el mismo hardware.
Técnicas de mitigación
Terminación TLS en el edge
La mitigación más efectiva transfiere el procesamiento del handshake TLS de los servidores de origen a los nodos edge con hardware optimizado para criptografía. El flujo funciona de la siguiente manera:
Sin terminación en el edge, cada cliente que accede a la aplicación fuerza al servidor de origen a ejecutar un handshake criptográfico completo. Bajo un ataque de agotamiento, el servidor de origen absorbe directamente toda la presión criptográfica.
Con terminación en el edge, los handshakes se completan en los nodos de la red de distribución. El servidor de origen mantiene únicamente una conexión TLS persistente con el edge — establecida una sola vez, no por cliente. El coste de handshake por usuario queda completamente eliminado del origen.
Rate limiting por IP — antes y después del handshake
El rate limiting de nuevos handshakes TLS por IP de origen interrumpe los ataques TLS Handshake Flood. Para el THC-SSL-DOS (que usa una única conexión), el control relevante es el límite de renegociaciones por sesión — parámetro configurable en OpenSSL (SSL_CTX_set_max_send_fragment) y en configuraciones de servidor como ssl_renegotiate_size de nginx.
Session resumption con rotación de STEK
Los Session Tickets permiten a los clientes legítimos evitar handshakes completos en las reconexiones, reduciendo la carga de CPU. La seguridad del mecanismo depende de la gestión correcta de las STEKs:
- Rota las STEKs con frecuencia (cada 24 horas o menos en entornos de alta sensibilidad).
- Usa STEKs por instancia de servidor — no compartidas entre nodos — para limitar el radio de un posible compromiso.
- Aplica rate limiting de tickets inválidos por IP para mitigar el Session Ticket Flood.
Deshabilitar la renegociación TLS (TLS 1.2 y anteriores)
Para servidores que aún usan TLS 1.2, deshabilitar la renegociación iniciada por el cliente elimina el vector THC-SSL-DOS sin afectar a los usuarios legítimos:
En nginx: ssl_renegotiation off;
En Apache: SSLRenegotiate off
En OpenSSL directamente: SSL_set_options(ssl, SSL_OP_NO_RENEGOTIATION);
Migración a TLS 1.3
El TLS 1.3 (RFC 8446) elimina la renegociación por diseño, reduce los RTTs de 2 a 1 y estandariza ECDHE como único mecanismo de intercambio de claves. Compatible con más del 96% de los navegadores modernos, la migración elimina la mayor superficie histórica de agotamiento TLS. Consulta también cifrados TLS y cómo afectan la seguridad y el rendimiento del handshake.
Señales de detección
| Indicador | Qué observar |
|---|---|
| CPU elevada sin tráfico HTTP proporcional | CPU al 100% pero bajo throughput de datos — típico del agotamiento por handshake |
| Alto número de conexiones TLS en handshake | ss -s u openssl s_client revelando muchas sesiones en estado handshaking |
| Caída en el HPS (Handshakes Per Second) | Métrica de capacidad criptográfica por debajo del baseline histórico |
| Pico de fallos de session ticket | Alto volumen de tickets inválidos por IP — señal de Session Ticket Flood |
| Muy baja tasa de completitud de requests HTTP | Conexiones TLS establecidas pero muy pocas peticiones procesadas de extremo a extremo |
| Alertas de agotamiento del pool de threads TLS | Logs del servidor indicando imposibilidad de iniciar nuevos handshakes |
Errores comunes y soluciones
Error: Tratar el agotamiento TLS como un problema de volumen de red. Solución: Los ataques de agotamiento TLS consumen CPU, no ancho de banda. Las herramientas de protección volumétrica (basadas en bps o pps) ni detectan ni mitigan este vector. El monitoreo debe centrarse en el HPS y el uso de CPU criptográfica.
Error: Asumir que HTTPS está automáticamente “protegido” por usar criptografía. Solución: La criptografía asimétrica es precisamente la fuente de la vulnerabilidad. Proteger HTTPS contra el agotamiento requiere terminación TLS en el edge y rate limiting de conexiones y renegociaciones.
Error: No migrar de TLS 1.2 a TLS 1.3 por preocupaciones de compatibilidad. Solución: TLS 1.3 es compatible con más del 96% de los navegadores modernos. La ventana de incompatibilidad es mínima; los beneficios de seguridad y eficiencia son sustanciales.
Error: Usar RSA 2048 o 4096 cuando ECDSA está disponible. Solución: ECDSA P-256 ofrece una seguridad equivalente a RSA 3072 con un coste computacional por firma mucho menor. La migración eleva el HPS del servidor y reduce el coste por handshake.
Error: No rotar las STEKs periódicamente. Solución: Las STEKs estáticas amplían el impacto de un posible compromiso y facilitan el Session Ticket Flood. Rota las STEKs al menos cada 24 horas.
Preguntas frecuentes
¿Cuál es la diferencia exacta entre THC-SSL-DOS y TLS Handshake Flood? THC-SSL-DOS usa una única conexión TCP persistente y fuerza múltiples renegociaciones en ella — cada renegociación es un handshake completo sin coste adicional de TCP para el atacante. TLS Handshake Flood abre múltiples conexiones TCP nuevas, una por handshake. THC-SSL-DOS es más eficiente para el atacante por handshake inducido; TLS Handshake Flood es más fácil de escalar con una botnet. TLS 1.3 elimina el vector THC-SSL-DOS al eliminar la renegociación.
¿Por qué el servidor ejecuta la operación más costosa y no el cliente? En el handshake TLS, el servidor debe probar su identidad generando una firma criptográfica con su clave privada — una operación que implica exponenciación modular (RSA) o multiplicación escalar en curva elíptica seguida de generación de firma (ECDSA/Ed25519). El cliente solo verifica la firma usando la clave pública del servidor, que es órdenes de magnitud más rápido. Esta asimetría es intrínseca al diseño de la infraestructura de clave pública (PKI).
¿Qué es el HPS y cómo se mide?
HPS (Handshakes Per Second) es la métrica de throughput criptográfico de un servidor — cuántos handshakes TLS puede procesar por segundo antes de saturar la CPU. Mídelo con openssl speed ecdsa ecdhx25519 rsa2048 para comparar algoritmos, o usa herramientas como wrk y h2load para medir el HPS real con tráfico HTTPS simulado. Los servidores con Intel QAT tienen un HPS sustancialmente mayor para cargas de trabajo RSA.
¿Qué es ECH y por qué crea una nueva superficie de ataque? Encrypted Client Hello (ECH) cifra el ClientHello interno de TLS 1.3 usando HPKE (Hybrid Public Key Encryption). Esto mejora la privacidad del usuario al ocultar el SNI de los observadores de red. El nuevo vector de ataque: un atacante puede enviar ClientHellos ECH fabricados, forzando al servidor a ejecutar operaciones de descapsulamiento HPKE en masa — una operación computacionalmente no trivial — antes de determinar que el ticket es inválido.
¿Pueden los Session Tickets explotarse sin comprometer la STEK? Sí. Incluso sin conocer la STEK, un atacante puede enviar tickets fabricados (basura criptográfica) en masa. El servidor debe intentar descifrarlos antes de confirmar que son inválidos — coste AES-CBC/GCM por ticket. El rate limiting de tickets inválidos por IP es la mitigación principal.
¿El mTLS aumenta significativamente la superficie de agotamiento? Sí, de forma sustancial. En mTLS, el servidor ejecuta operaciones adicionales por handshake: verificación de la firma del certificado del cliente, validación de toda la cadena de certificados del cliente (que puede incluir CAs intermedias), y — dependiendo de la configuración — una consulta OCSP o verificación de CRL para confirmar que el certificado del cliente no ha sido revocado. Cada uno de estos pasos añade coste criptográfico y, en el caso de OCSP, latencia de red. En entornos mTLS de alta escala, la aceleración de hardware y el caché agresivo de respuestas OCSP son esenciales para mantener un HPS adecuado.
¿TLS 1.3 elimina completamente el riesgo de agotamiento? Elimina el vector de renegociación (THC-SSL-DOS). Pero el handshake inicial sigue requiriendo ECDHE y generación de firma ECDSA/Ed25519 — operaciones con coste no negligible. El TLS Handshake Flood sigue siendo posible contra TLS 1.3, aunque el coste por handshake es menor que con RSA-2048 o RSA-4096, lo que eleva el umbral de saturación. La eliminación de la renegociación es el mayor beneficio.
Cómo implementar en Azion
Azion protege contra el agotamiento de handshake TLS con terminación TLS distribuida en el edge:
- Terminación TLS en los data centers de Azion: Los handshakes TLS se terminan en los data centers de Azion, no en los servidores de origen de los clientes. El origen nunca procesa handshakes con usuarios finales — mantiene únicamente una conexión segura con el edge.
- TLS 1.3 por defecto: Azion soporta y recomienda TLS 1.3, eliminando la renegociación y reduciendo el coste por handshake y la superficie de ataque respecto a TLS 1.2.
- Session resumption con gestión de STEK: Azion implementa session tickets con rotación de claves, reduciendo el coste de reconexión de clientes legítimos y mitigando el Session Ticket Flood por volumen y por IP.
- Rate limiting de conexiones TLS: El edge de Azion aplica límites de nuevos handshakes TLS por IP de origen, bloqueando tanto TLS Handshake Floods como intentos de renegociación masiva antes de que consuman recursos de procesamiento criptográfico.
Aprende más en la documentación de Certificate Manager de Azion.