A TLS renegotiation attack works by making the server repeat the expensive half of a handshake the client barely pays for, rather than by flooding the network with volume. That asymmetry is why a thorough DDoS test exercises it: a single low-bandwidth machine can drive a defender's CPU to saturation while the network link sits almost idle. It is a Layer 6/7 vector that spends compute instead of bandwidth, which is what makes it dangerous to a stack tuned to watch for volume.
How the cost asymmetry works
A TLS handshake is deliberately lopsided. The server performs the costly private-key operation on every handshake, the RSA decryption or the signing step of an ECDHE exchange, while the client's side of the same exchange is comparatively cheap. The measurements published with the original THC-SSL-DOS release put the server's work at roughly ten to fifteen times the client's. That gap is harmless in normal use, where handshakes are occasional; it turns into a weapon the moment a client can demand them on repeat.
There are two ways to demand them. The classic form abuses client-initiated renegotiation: on one established connection the client asks to renegotiate the session keys over and over, and each request forces the server through another full key exchange. One TCP connection, almost no bandwidth, and the server burns a core. The second form skips renegotiation and opens many short connections, each completing one fresh handshake before being discarded. The renegotiation variant is the more economical of the two, because it reuses a single connection and never pays to set up new ones. That connection-churn form shades into an SSL flood, the sibling that exhausts the same crypto machinery by connection volume rather than by renegotiating a live session.
Why it matters under attack
The defining property is that this vector spends compute, not bandwidth, so every control tuned to volume looks the other way. The traffic graph shows a trickle while the CPU graph shows a server on its knees. Like the low and slow attack family it costs the attacker next to nothing to sustain, but the resource it drains is processor time on asymmetric cryptography rather than a connection pool. A defense that comfortably absorbs a large volumetric flood can still fall to a handshake storm arriving over a single home broadband line, which is precisely why it belongs on the test plan next to the volumetric cases instead of being assumed away by upstream scrubbing capacity.
The clean fix has existed for years and is a configuration choice, not a scrubbing problem. Client-initiated renegotiation can be disabled outright, and most servers now refuse it by default. TLS 1.3 goes further and removes renegotiation from the protocol entirely, replacing it with lighter key updates and post-handshake authentication that never hand the client a CPU lever. What remains after that is the plain cost of the initial handshake itself, which moving TLS termination to a hardware accelerator or a dedicated edge tier changes but does not erase.
What a DDoS test measures
Because the choke point is compute, the test is a compute test. It drives handshakes or renegotiations at a rising rate and records where server CPU saturates and real clients start failing to connect, rather than reporting any bits-per-second figure. Three questions decide the result: is client-initiated renegotiation disabled, does moving to TLS 1.3 with renegotiation removed flatten the curve, and does terminating TLS on a separate offload tier shift the point of first failure away from the origin. This is an application-layer attack whose whole signature lives above the network, so a volumetric harness alone will never surface it. What that means for the defender's actual decision, which knobs to set and where to terminate TLS, is worked through in Application-Layer (L7) DDoS Testing.