ddos-sim.com All simulations Build a test plan

Layer 6 · Presentation · tls_exhaustion_check

SSL/TLS exhaustion test

The tls_exhaustion_check simulation completes a full TLS handshake per operation to expose the crypto cost of handshake pressure on a domain you own. It targets the asymmetric expense of setting up encryption — cheap for a client, costly for your server.

Layer L6 Protocol TLS Command tls_exhaustion_check Access After verification

What a TLS handshake flood does

A TLS exhaustion attack forces the server to perform the expensive part of the handshake — key exchange and signing — over and over, often abandoning each session right after. The asymmetry is the weapon: a client spends little, while the server burns CPU on every negotiation, so a modest request rate can saturate a termination node.

How ddos-sim.com simulates it safely

ddos-sim.com completes a genuine, full TLS handshake per operation against a single verified domain pinned to a public address, within the rate and concurrency limits for that domain. It measures real negotiation cost without spoofing or malformed handshakes.

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

  • CPU cost of key exchange and certificate signing
  • TLS termination and offload capacity
  • Session-resumption and ticket effectiveness
  • Scaling of the termination tier under handshake pressure
  • Cipher-suite choices and their compute cost

When to run a TLS exhaustion test

Run a TLS exhaustion test when the cost of the handshake — not the request that follows — is what you need to size.

  • You terminate TLS at the origin and want to measure CPU headroom under a burst of full handshakes.
  • A load balancer or CDN offloads TLS and you need to confirm it absorbs handshake pressure instead of the origin.
  • You're evaluating session resumption, OCSP stapling, or keyless/hardware offload under load.

How to run a ssl/tls exhaustion test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the tls_exhaustion_check command to a timeline in the portal and set the target path or 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 the recorded latency, status codes, and worker timeline to find where your service starts to bend.

Configure a ssl/tls exhaustion test in the portal →

Reading the results

Resilient: Handshake latency stays flat, CPU keeps headroom, and session resumption keeps the marginal cost of each new connection low.

Under strain: TLS CPU saturates, handshake latency climbs, and new HTTPS connections slow or fail while established ones continue.

Availability & limits

SSL/TLS exhaustion tests are available after your domain is verified and are priced per engagement — request a quote.

Frequently asked questions

What mitigations does this test typically point to?

Enabling session resumption and TLS tickets, offloading termination to a CDN or dedicated hardware, choosing efficient cipher suites, and scaling the termination tier independently of the application.

How is it different from an HTTPS flood?

The HTTPS flood measures whole-request behavior over TLS, while tls_exhaustion focuses on the handshake itself to isolate the CPU cost of repeated negotiation.

Rehearse the ssl/tls exhaustion against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations