When a TLS terminator's CPU pins at 100 percent while its link carries a few hundred megabits and the request log is almost empty, something is opening connections and leaving before it ever asks for a page. That is an SSL flood, also called a TLS handshake flood, the case a DDoS test runs to find how many fresh handshakes per second a service can actually pay for. The attacker connects, drives the server through a full handshake, abandons the session and connects again, so the cost is cryptography rather than bandwidth.
How an SSL flood works
The economics are shared with the TLS renegotiation attack: the server's private-key operation is far more expensive than anything the client is obliged to do. The renegotiation form spends that asymmetry over one held connection. The SSL flood spends it by connection churn, which is why it survived when renegotiation was switched off and why TLS 1.3, which removed renegotiation altogether, does nothing to stop it.
The client's side is even cheaper than the protocol suggests. In a TLS 1.3 handshake the server generates its key share and signs the transcript before the client has to do anything more than send a hello. An attacker can reuse a single key share across every connection, skip verifying the certificate, never send Finished, and close. In the older RSA key exchange the client could send random bytes in place of an encrypted secret, and the server would only discover that after paying for the decryption.
What the attacker cannot do is spoof. A handshake rides on a completed TCP connection, so every source address is real, the same constraint a TCP connection flood works under. That rules out the anti-spoofing controls and points the attack at botnets and rented proxies.
Why it matters under attack
The certificate decides the breaking point more than the hardware does. On a commodity x86 core, openssl speed puts RSA-2048 signing at roughly a couple of thousand operations a second, and ECDSA P-256 signing at tens of thousands. A terminator serving an RSA certificate can fall over at a handshake rate an ECDSA-served one barely registers, and nothing about the network graph tells you which one you have.
Session resumption does not help against it. Resumption makes returning legitimate clients cheap, which is valuable, but an attacker simply never presents a ticket and gets a full handshake every time. The share of resumed handshakes during an incident is a useful signal: when it collapses, the new connections are not your users.
The traffic is also encrypted at the point where most filters would want to look at it. Nothing about the request is visible until the handshake the attacker is abusing has already been paid for. The controls that work act before or at the hello: per-source limits on new connections, and fingerprinting the ClientHello with JA3 or JA4, since flood tooling tends to send one fixed hello while real browsers vary. Where TLS terminates matters as much as how. A CDN edge or a dedicated terminator tier absorbs the flood in front of the origin; an origin whose address is known takes it directly.
What a DDoS test measures
The headline number is the new-handshake rate at which each terminator in the path saturates and real clients start timing out, measured with resumption disabled on the test side so the figure is honest. It is reported per terminator and per certificate type, because an RSA fallback certificate on one listener can set the ceiling for the whole service.
The test then checks whether per-source connection limits engage before CPU does, whether the edge can match on a ClientHello fingerprint without blocking browsers, and whether the origin stays out of the handshake path entirely when the edge is in front. Handshake cost is one of several places above the network layer where CPU, not bandwidth, decides the outcome, and Application-Layer (L7) DDoS Testing sets out the rest.