# TLS Handshake Floods: Attacking the Most Expensive Part of the Connection > A handshake costs the server far more than it costs the client. Attackers know the ratio, and a few thousand connections per second can exhaust a machine that shrugs off much larger request floods. - Category: Attack Analysis - Author: Akarguard Team, Security Engineering - Published: Sep 13, 2026 - Canonical: https://akarguard.net/blog/tls-handshake-flood --- Encryption is asymmetric in more ways than one. Completing a TLS handshake requires meaningfully more work from the server than from the client, and that imbalance is the whole attack. A handshake flood never sends a single HTTP request; it opens connections, begins negotiation, and lets the server do the expensive part. ## Why the Server Pays More During a handshake the server performs private key operations, allocates session state, and holds a socket while the client takes its time. A client that never intends to complete the exchange skips most of that cost. Multiply by a few thousand concurrent attempts per second and the processor is fully occupied doing cryptography for connections that will never carry a request. > **Renegotiation made it worse** — Older protocol versions allowed a client to request renegotiation inside an established connection, repeating the expensive step without opening a new socket. Modern versions removed it, which is one reason keeping TLS libraries current is itself a DDoS control. ## What It Looks Like - Processor use is pinned while request logs stay almost empty — the traffic never becomes an HTTP request, so it never reaches the access log. - Connection counts climb far beyond the number of active sessions. - Handshake failure and incomplete connection counters rise sharply. - Legitimate users see timeouts during connection rather than slow pages: the site never gets far enough to be slow. ## Defences - Terminate TLS at an edge built for it, so the cost lands on infrastructure designed to absorb it rather than on your application host. - Limit new connections per source address, separately from request rate limits — the flood is connections, not requests. - Keep handshake timeouts short so a client that stalls mid-negotiation releases resources quickly. - Prefer modern cipher suites and current library versions; the performance difference under load is substantial. - Monitor handshake failures as a first-class metric. It is often the earliest signal available, precisely because nothing appears in the request logs. ## The Detection Gap Most application monitoring starts at the request. A handshake flood lives entirely before that line, which is why teams sometimes spend an hour investigating a database that turns out to be perfectly healthy. If your dashboards cannot show connections and handshakes separately from requests, you have a blind spot exactly where this attack operates. --- Source: Akarguard Security Blog (https://akarguard.net/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.