ddos-simulation.com
Build a test plan

Layer 7 · TLS · tls_renegotiation_flood

TLS renegotiation flood test

The tls_renegotiation_flood simulation repeatedly triggers client-initiated TLS renegotiation over a single connection to a domain you own, forcing the server to redo the asymmetric-crypto work of a handshake — key exchange and certificate signing — at minimal client cost. It validates your renegotiation policy and, where renegotiation is permitted, the CPU headroom of the handshake path, while staying attributable and in-bounds.

Layer L7 Protocol TLS Command tls_renegotiation_flood Access Reviewed engagement

What a TLS renegotiation flood does

A TLS renegotiation flood — the classic "THC-SSL-DOS" shape — opens one TLS connection and then renegotiates it over and over. Each renegotiation makes the server repeat the most expensive part of a handshake: the ephemeral key exchange and, above all, signing its key-exchange parameters with the certificate's private key. The client, by contrast, pays almost nothing. That asymmetry means a handful of connections can impose disproportionate CPU load — if, and only if, the server still allows client-initiated renegotiation.

How ddos-simulation.com simulates it safely

ddos-simulation.com opens TLS connections to a single verified domain pinned to a public address and issues renegotiations at a bounded rate from the worker's own address — no spoofing, and no application data is ever sent. Health checks watch the target throughout, and the run aborts itself the moment a threshold you set is crossed. Where the server refuses renegotiation, the test records that cleanly as a pass.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.

What the test exercises

  • Whether the server permits client-initiated renegotiation at all
  • The CPU cost of repeated key exchange and certificate signing, where it is permitted
  • TLS termination and reverse-proxy configuration hardening
  • Rate limiting and anti-abuse policy on the TLS handshake path
  • Time-to-degrade and recovery once the test stops

When to run a TLS renegotiation flood test

Run a TLS renegotiation flood test when you need to confirm your TLS termination is configured to refuse this classic denial-of-service, or to measure its cost where it is still allowed.

  • You run TLS 1.2 anywhere in the stack and want evidence that client-initiated renegotiation is disabled.
  • You operate legacy endpoints or appliances whose renegotiation policy you cannot easily audit from configuration alone.
  • You want a documented, isolated result for the renegotiation vector as part of a broader TLS resilience review.

How to run a TLS renegotiation flood test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the tls_renegotiation_flood command to a timeline in the portal and set the target port, rate, and duration.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review whether renegotiation was accepted or refused, along with latency and the worker timeline.

Configure a TLS renegotiation flood test in the portal →

Reading the results

Resilient: The server refuses client-initiated renegotiation (TLS 1.3, or hardened TLS 1.2) — renegotiation attempts are rejected and the test confirms you are not exposed.

Under strain: Renegotiation is accepted and handshake CPU climbs as the server repeats key exchange and signing, with latency rising on the TLS path — a sign client-initiated renegotiation should be disabled.

Availability & limits

The TLS renegotiation flood is reviewed and approved before it runs (a manual review, beyond verifying you own the domain) and is priced per engagement — request a quote.

Frequently asked questions

What if my server refuses client-initiated renegotiation?

That is a passing result. Modern TLS 1.3 removes renegotiation entirely, and hardened TLS 1.2 servers disable client-initiated renegotiation — so the test confirms your configuration correctly refuses it. The vector only imposes load on legacy TLS 1.2 deployments that still permit client-initiated renegotiation.

How is this different from a TLS exhaustion test?

A TLS exhaustion test opens a new connection for each full handshake. A renegotiation flood reuses a single connection and triggers handshake after handshake on it, so the server repeats the expensive asymmetric-crypto work — key exchange and signing — while the client pays almost nothing. It maximises the ratio of server crypto to client and network cost.

Rehearse a TLS renegotiation flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations