HTTP/2 Rapid Reset is a widely-known DDoS attack method, leveraged by attackers using botnets of various sizes. However, Rapid Reset is uniquely effective at orchestrating the slowdown or crashing of web servers, reverse proxies, and other services with relatively-small botnets.

Cloudflare, Google Cloud, and many more of the internet's largest networking and cloud vendors recorded numerous Rapid Reset attacks against customers. These vastly exceeded previous HTTP attacks in size, even topping out at 398 million requests per second (RPS). The vast majority of these attacks occurred between August 2023 and October 2023. 

Noted under CVE-2023-44487, security researchers at the MITRE Corporation assigned the attack method a severity score of 7.5 — highly severe. Once the attack method was publicized, all organizations providing (or supporting) HTTP/2 services were advised to patch this vulnerability to prevent further exploitation.

How does HTTP/2 Rapid Reset work?

HTTP/2 Rapid Reset exploits a weakness in the HTTP/2 protocol's stream multiplexing feature. Multiplexing normally boosts processing throughput efficiency for concurrent requests at scale, but can be a powerful attack vector when abused. 

Specifically, attackers would abuse the RST_STREAM frame function to repeatedly open an unbounded number of streams — then unilaterally cancel them — over the same connection. Since the quantity of open streams is only logged at the connection level, any reset streams that switched to a closed state would not count towards the overall stream limit. Consequently, an attacker could exhaust all available connections — shutting out legitimate users.

These conditions enabled attackers to bypass limitations and overwhelm servers with a constant assault of processes. These attacks were resource-intensive for web servers and proxies, but required few resources to actually carry out. 

Theoretically, Rapid Reset wasn't a threatening problem for servers that could quickly process these state changes. However, any delays resulting from process hangups or resource exhaustion could cause issues.

Does HAProxy protect against HTTP/2 Rapid Reset?

Yes, and HAProxy is not impacted despite handling copious amounts of HTTP/2 traffic. If you wish to detect clients attempting to exploit HTTP/2 Rapid Reset you can add the glitch_rate metric to a stick table in HAProxy Enterprise (for example). 

To learn more about HTTP/2 Rapid Reset and how we guard against it, read our announcement blog post.