Radware SSL/Encrypted DDoS Protection — HTTPS Floods & TLS Attack Mitigation

① Why encrypted DDoS is hard — the payload is hidden and the cost curve is inverted

Almost all web traffic is now encrypted, and attackers happily hide their DDoS inside the TLS tunnel. The first problem is visibility: a defender watching the wire sees only encrypted bytes, not the malicious GET/POST requests, so classic content inspection is blind.

The second problem is worse — the cost curve is inverted. A TLS handshake costs the server far more than the client. Radware cites SSL/TLS connections requiring up to 15x more CPU on the destination than on the requester. That asymmetry turns a single small attacker into a heavyweight: a low-bandwidth flood can burn the origin's CPU while the link looks almost idle.

So encrypted DDoS is the nasty combination of blind defenders and a target that tires first. The naive fix — decrypt everything to see inside — adds latency, breaks privacy, and demands key management you may not even have the keys for.

② The encrypted attack zoo — how each one exhausts a target

Encrypted DDoS comes in several flavours. An HTTPS flood is a Layer-7 wave of encrypted GET/POST requests aimed at exhausting the web application — often low-and-slow so it mimics a legitimate flash crowd. A TLS handshake flood opens many sessions and forces the expensive key-exchange over and over, drowning the server in crypto work.

The classic CPU killers

An SSL renegotiation attack — the famous THC-SSL-DOS — uses just one TCP connection that repeatedly renegotiates keys, exploiting the lopsided cost so a single machine can overload an SSL server. Encrypted SYN floods add connection-table pressure on top. Each variant targets a different resource — CPU, connection state, or application threads — but they share one trait: wrapped in TLS, they look like normal encrypted traffic until you measure behaviour.

③ How Radware mitigates — keyless behavioral detection, stateless, optional decryption

Radware's DefensePro HTTPS Flood Protection module (the engine behind DefenseSSL) learns normal HTTPS behaviour, then detects attacks over encrypted traffic using behavioral algorithms that blend rate-based and non-rate-based parameters — rate-invariant and rate-variant statistics. No content inspection, no plaintext — so it works keyless, with no private decryption key.

Keyless protection is also stateless: it keeps no per-connection state, so the mitigation device itself can't be exhausted by a state-table attack the way a stateful proxy can. Mitigation escalates gradually — from non-intrusive rate-limiting (which needs no SSL server cert or key) up to active client challenges — to minimise collateral damage to real users.

When you do decrypt

When keys are available and you want higher accuracy, DefensePro can decrypt suspected traffic to issue Layer-7 challenges, then re-encrypt before passing validated traffic onward. From 8.26.0.0+, full-session decryption decrypts whole HTTPS sessions and feeds them to Signature Protection and Traffic Filters when deep payload inspection is required.

④ Trade-offs and deployment — keyless vs decryption, and who needs which

The core trade-off is keyless behavioral versus full decryption. Keyless adds no added latency (no per-packet crypto), preserves privacy, and removes the key-management burden — but it works on behaviour, not payload. Full decryption gives deep payload visibility and higher accuracy, at the cost of latency, the privacy of seeing plaintext, and managing certificates and keys, so Radware invokes it selectively.

Choose by who you are

For ISPs and carriers, keyless is essential — providers almost never receive tenant private keys, so behavioral, stateless protection is the only option that scales across many tenants. For an enterprise that owns its own keys and needs signature-level inspection, selective decryption is on the table. The failure mode to avoid is assuming you must decrypt everything: that breaks privacy, adds latency, and stalls the moment you don't hold the keys.