Google mitigates the largest DDoS attack in history – 398 million requests per second

Today, Google Cloud elucidated a recently emergent type of attack in their blog: the HTTP/2 Rapid Reset. Since August, attackers have leveraged this technique against customers of Google’s cloud platform. In one audacious instance, an attacker dispatched an astonishing 398 million requests within a singular second, setting the record for the highest requests per second in an assault.

At its core, HTTP/2 was conceived with efficiency as its primary objective. One of its notable features is the enhancement of TCP connection utilization. Contrary to the sequential handling of each request in HTTP/1.1, HTTP/2 facilitates multiple concurrent streams within a single TCP connection, with each stream corresponding to an individual HTTP request.

Theoretically, the maximum number of concurrently opened streams should be dictated by the target server. However, in practice, a client’s single request can initiate 100 streams, which the server will then process since it cannot unilaterally impose restrictions.

This concurrent modality allows a hundredfold increase in the utilization of each connection, a vast improvement over the queue-based handling of HTTP/1.1.

HTTP/2 Rapid Reset vulnerability has now been earmarked as a security concern, labeled as CVE-2023-44487. Strictly speaking, this isn’t a security flaw but rather an exploitation of HTTP/2’s inherent features by malicious actors. Nonetheless, Google deemed it imperative to alert the industry, hence submitting a vulnerability report.

Another hallmark of HTTP/2 is RST_STREAM. This protocol permits clients to send RST_STREAM frames to servers, nullifying previous streams without requiring mutual negotiations; clients can unilaterally execute this.

HTTP/1.1 and HTTP/2 request and response pattern

Upon the server’s receipt of an RST_STREAM frame, the cancellation is immediately effected before processing any other data from that TCP link.

How did the attackers maneuver? They exploited this feature, sending an RST_STREAM frame immediately after dispatching a request frame. Once an attacking client initiates this process, it swiftly resets the request. Despite the cancellation, the HTTP/2 connection ostensibly remains active.

This modus operandi allows for frenzied dispatching of requests followed by RST_STREAM frames. Attackers do not exceed the concurrent stream limit of 100. Utilizing numerous attacking clients within the ambit of these 100 concurrent streams, they can dispatch multiple requests per second (Note: Multiple requests can be made within a second; the 100 stream limit pertains to a single request, but sending multiple requests per second amplifies the attack).

Such onslaughts render the number of requests independent of RTT (Round-Trip Time) and solely contingent upon the server’s available network bandwidth.

In quintessential HTTP/2 server implementations, the server still bears the brunt of extensive labor for canceled requests, such as allocating new stream data structures, parsing queries, executing header compressions, and mapping URLs to resources. For reverse proxy implementations, requests can be proxied to backend servers prior to processing the RST_STREAM frame.

Conversely, attackers incur negligible costs for dispatching requests. Their network bandwidth consumption remains minimal, facilitating the amplification of their attack’s magnitude at an extremely low overhead.

Owing to protocol disparities, Google posits that an HTTP/2 DDoS cannot be seamlessly transposed to HTTP/3 or QUIC DDoS. To date, Google hasn’t observed significant attack vectors pertaining to HTTP/3 DDoS. Regardless, Google still advocates for HTTP/3 servers to proactively implement mechanisms to curtail the workload of individual transmission connections, employing strategies analogous to the mitigation for HTTP/2 DDoS.