What is an SSL flood attack?

02Why the handshake is so one-sided

The attack works because of a cost asymmetry that is inherent to public-key cryptography, not a bug. In a classic RSA handshake the server performs a private-key operation that is far more expensive than the client's matching public-key operation. When the group behind a 2011 handshake-flood tool claimed the server needs fifteen times the client's processing power, the engineer Vincent Bernat measured it: about six times the client's CPU with a 2048-bit RSA certificate and an RSA key-exchange cipher suite, and about a hundred times once a tool skipped the client's real cryptographic work and sent messages of merely the right length.

A simple benchmark shows the raw gap. On one current x86-64 server core, repeated openssl speed runs completed RSA-2048 private-key (signing) operations at roughly 2,500 to 2,900 per second, while the matching public-key (verify) operation, the cheaper client-side work, ran at roughly 42,000 to 47,000 per second: about sixteen times faster. Absolute figures vary by CPU; the ratio barely moves. That means one modest client can request handshakes far faster than one server core can satisfy them, which is the whole attack in a sentence.

03The renegotiation attack

The renegotiation attack sharpened the SSL flood. In TLS 1.2 and earlier, a client could ask to renegotiate the cryptographic parameters inside an already-open connection, triggering a fresh handshake, and it could do so repeatedly. A single TCP connection could therefore drive hundreds of expensive handshakes, so one machine could attack a much larger server without even opening many connections. A well-known proof-of-concept tool demonstrated exactly this in 2011.

The underlying weakness was catalogued as CVE-2011-1473: OpenSSL did not restrict client-initiated renegotiation, which made it easier to cause denial of service through CPU consumption by renegotiating many times in one connection. As the record itself notes, it is also arguable that limiting renegotiation is the server deployment's responsibility rather than the library's, and both sides of that have since been addressed.

04How TLS 1.3 and modern servers close it

The structural fix is TLS 1.3, which simply forbids renegotiation. RFC 8446 states that a server which has negotiated TLS 1.3 and then receives a ClientHello at any other time must terminate the connection. There is no in-connection renegotiation to abuse; where a session genuinely needs new keys, TLS 1.3 uses a lightweight KeyUpdate message instead of a full handshake. Testing with OpenSSL 3.0 showed the same from the client side: on a TLS 1.3 connection the library refuses to even start a renegotiation ('wrong ssl version'), while a KeyUpdate goes through without a new handshake.

On the older protocols the servers themselves refuse the dangerous path. Modern OpenSSL disables client-initiated renegotiation by default; enabling it now takes a deliberate option. Common web servers have refused it for years. Testing a current build confirmed that a client-initiated renegotiation on a TLS 1.2 connection is rejected with a 'no renegotiation' alert, so the classic renegotiation flood no longer works against a default configuration.

# Open a TLS 1.2 session, then type R to request renegotiation.
# A hardened server answers with a 'no renegotiation' alert and the attempt fails.
openssl s_client -connect example.com:443 -tls1_2
# ... after CONNECTED, type:  R
# expect:  SSL routines:ssl3_read_bytes:no renegotiation

# Confirm the server offers TLS 1.3 (which forbids renegotiation outright).
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher'

05Session resumption and offload

Beyond removing renegotiation, the way to survive a handshake flood is to do fewer full handshakes and to pay less for each. Session resumption lets a returning client re-establish a connection from a previously negotiated secret instead of a full key exchange, which is dramatically cheaper for the server. Testing confirmed resumption working on both TLS 1.2 (via a session ticket) and TLS 1.3, where the second connection is reported as reused rather than new. If nginx also verifies client certificates, check CVE-2025-23419 first: on unpatched builds a TLS 1.3 session resumed across virtual servers could skip that check.

The other lever is to not terminate TLS on the origin at all. Terminating at an edge or reverse proxy means the expensive handshake work happens on infrastructure built to absorb it, and the origin sees already-decrypted traffic over reused connections. Combined with an EC certificate and keep-alive so each visitor's many requests share one handshake, these measures raise the flood rate a server can withstand by a large multiple.

• Offer TLS 1.3, which removes renegotiation and completes its handshake in one round trip
• Leave client-initiated renegotiation disabled, which is the default in current servers and libraries
• Serve an ECDSA (P-256) certificate, which signs roughly fourteen times faster per core than RSA-2048
• Enable session resumption so returning clients skip the full handshake
• Terminate TLS at an edge or proxy so handshake cost lands on capacity built for it, not the origin
• Keep connections alive so a visitor's many requests reuse one handshake

06The SSL garbage flood variant

A related, blunter variant does not bother completing valid handshakes at all. It opens TCP connections to the TLS port and sends junk, or starts a handshake and abandons it, forcing the server to allocate connection state and begin cryptographic work that never finishes. In a test against nginx, an abandoned connection was logged as 'client timed out while SSL handshaking' only once the timeout expired, and junk bytes as an invalid request, each holding a connection slot until then.

The defences overlap with the handshake-flood case but add connection discipline: cap concurrent connections per source, keep handshake timeouts short so an abandoned handshake is reclaimed quickly, and rate-limit new connections per address. These are the same tools used against a SYN flood and slow-connection attacks, applied at the TLS edge, and they pair naturally with per-client rate limiting.

07What a proxy can and cannot do here

An edge or reverse proxy is the right place to handle a handshake flood, within limits worth stating plainly. It can take the expensive TLS termination off the origin, enforce modern protocol versions, insist on resumption and an EC certificate, cap connections per source and reclaim abandoned handshakes quickly. That alone defeats the renegotiation attack and absorbs a great deal of handshake volume, because the origin stops seeing raw handshakes entirely.

What no layer can do perfectly is tell a determined attacker's valid handshakes apart from real ones purely at the TLS layer; a completed handshake from a fresh address looks like a visitor until it behaves otherwise. The honest levers against that are capacity and per-source rate limiting of new connections, so the attack has to be large and sustained to matter, and a dedicated DDoS mitigation network provides both. A proxy also does nothing for a flood aimed at a different service or at your name servers; defend each layer in its own place.