On Saturday 25 January 2025 at 06:26 UTC, a TLS handshake exhaustion targeted a B2B SaaS customer in the Nordics. The attack peaked at 831.0 million requests per second and lasted 190 minutes. Traffic originated from 3587 autonomous systems in 46 countries, predominantly residential proxy networks.
| Vector | TLS handshake exhaustion |
| Peak | 831.0 million requests per second |
| Duration | 190 min |
| Time to mitigation | 0.841 s |
| Attack traffic reaching origin | 0.007% |
| Legitimate traffic challenged | 0.76% |
Timeline
The attack was preceded by a publicly announced sales event. Request rates on the targeted routes exceeded their hourly baseline by a factor of 756 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
Checkout conversion was unchanged compared with the same hour of the previous week.
Recommendations
- Keep origin IPs out of public DNS history.
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Review allow-listed partner ranges quarterly.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Machine-readable ranges are at /ips.json and via the API.
Do you publish the edge IP ranges in a machine-readable format?
Nice to read a vendor blog that admits what went wrong.
Nice to read a vendor blog that admits what went wrong.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
This matches what we see in iGaming around big matches.
Would love a follow-up on how you handle HTTP/3 fingerprinting.