HTTPS / TLS application flood
HTTP traffic over TLS adds handshake CPU cost before any request is processed. High parallel HTTPS GET/POST floods stress SSL termination, WAF, and origin workers together.
How it works
- TCP handshake completes, then ClientHello starts TLS negotiation.
- Server responds with certificate chain and key exchange — CPU intensive at scale.
- Encrypted application data carries GET/POST requests (Application Data records).
- Volumetric thresholds alone may miss L7 HTTPS floods because request rates look moderate.
Packet flow (illustrative)
Engarde node Target
→SYN · SYN-ACK · ACKTCP
→ClientHello
←ServerHello + Certificate
→Application Data: GET / …
Illustrative flow — not a live capture.
Typical pattern TLS + HTTP/S GET/POST
Engarde metric RPS, latency, CPU proxy
Layer L7 + crypto
What to watch in Engarde
- TLS handshake rate vs. completed request rate on Target Monitor.
- 502/503 from load balancer when SSL daemon saturates.
- Difference between HTTP and HTTP/S runs on the same URL.
Running this simulation
Use HTTP/S attack type in Engarde DDoS with method flag GET, POST, etc. Distributed nodes open TLS sessions to your authorized target; stop instantly with End test.
Mitigation perspective
TLS offloading, session resumption, rate limits at CDN/WAF, and autoscaling of SSL frontends. Validate with controlled HTTPS simulation.