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.