On Thursday 10 June 2021 at 15:09 UTC, a TLS handshake exhaustion targeted a healthcare portal customer in Southeast Asia. The attack peaked at 599.4 million requests per second and lasted 139 minutes. Traffic originated from 3108 autonomous systems in 115 countries, predominantly misconfigured open reflectors.
| Vector | TLS handshake exhaustion |
| Peak | 599.4 million requests per second |
| Duration | 139 min |
| Time to mitigation | 0.371 s |
| Attack traffic reaching origin | 0.077% |
| Legitimate traffic challenged | 0.37% |
Timeline
The attack was preceded by an extortion email received two days earlier. Request rates on the targeted routes exceeded their hourly baseline by a factor of 278 within 22 seconds. The risk score of participating clients crossed the challenge threshold automatically and proof-of-work difficulty rose with origin load.
What the customer saw
A brief increase in p99 latency of 98 ms during the first minute, then normal service.
Recommendations
- Review allow-listed partner ranges quarterly.
- Add a dedicated rate limit for the targeted route.
- Enable authenticated origin pulls.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Verified good bots and allow-listed partners bypass challenges entirely.
The point about origin IPs leaking through certificate transparency logs is underrated.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
This matches what we see in iGaming around big matches.