# Inundaciones de handshake TLS: atacar la parte más cara de la conexión > Un handshake le cuesta al servidor mucho más que al cliente. Los atacantes conocen la proporción, y unos pocos miles de conexiones por segundo pueden agotar una máquina que ignora inundaciones de peticiones mucho mayores. - Category: Análisis de ataques - Author: Equipo Akarguard, Ingeniería de Seguridad - Published: Aug 6, 2025 - Canonical: https://akarguard.net/es/blog/inundacion-handshake-tls --- El cifrado es asimétrico en más de un sentido. Completar un handshake TLS requiere significativamente más trabajo del servidor que del cliente, y ese desequilibrio es todo el ataque. Una inundación de handshakes nunca envía una sola petición HTTP; abre conexiones, inicia la negociación y deja que el servidor haga la parte cara. ## Por qué el servidor paga más Durante un handshake el servidor realiza operaciones con la clave privada, asigna estado de sesión y mantiene un socket mientras el cliente se toma su tiempo. Un cliente que nunca pretende completar el intercambio se salta la mayor parte de ese coste. Multiplica por unos pocos miles de intentos concurrentes por segundo y el procesador queda completamente ocupado haciendo criptografía para conexiones que nunca llevarán una petición. > **La renegociación lo empeoró** — Las versiones antiguas del protocolo permitían a un cliente solicitar renegociación dentro de una conexión establecida, repitiendo el paso caro sin abrir un socket nuevo. Las versiones modernas lo eliminaron, y por eso mantener las bibliotecas TLS al día es en sí mismo un control DDoS. ## Cómo se ve - El uso del procesador está clavado mientras los logs de peticiones siguen casi vacíos — el tráfico nunca se convierte en una petición HTTP, así que nunca llega al log de acceso. - Los recuentos de conexiones suben mucho más allá del número de sesiones activas. - Los contadores de fallos de handshake y de conexiones incompletas se disparan. - Los usuarios legítimos ven timeouts al conectar en vez de páginas lentas: el sitio ni siquiera llega lo bastante lejos para ser lento. ## Defensas - Termina el TLS en un edge hecho para ello, para que el coste caiga sobre infraestructura diseñada para absorberlo en vez de sobre tu host de aplicación. - Limita las conexiones nuevas por dirección de origen, aparte de los límites de tasa de peticiones — la inundación son conexiones, no peticiones. - Mantén cortos los timeouts de handshake para que un cliente que se estanca a mitad de negociación libere recursos rápido. - Prefiere suites de cifrado modernas y versiones de biblioteca actuales; la diferencia de rendimiento bajo carga es sustancial. - Monitoriza los fallos de handshake como una métrica de primera clase. A menudo es la señal más temprana disponible, precisamente porque nada aparece en los logs de peticiones. ## El hueco de detección La mayoría de la monitorización de aplicaciones empieza en la petición. Una inundación de handshakes vive por completo antes de esa línea, y por eso los equipos a veces pasan una hora investigando una base de datos que resulta estar perfectamente sana. Si tus paneles no pueden mostrar conexiones y handshakes por separado de las peticiones, tienes un punto ciego justo donde opera este ataque. --- Source: Akarguard Security Blog (https://akarguard.net/es/blog). Akarguard provides DDoS protection: traffic is proxied through our edge, attack traffic is filtered, and clean traffic reaches your origin. Reuse of this article with attribution and a link to the canonical URL is permitted.