HTTP/2 Rapid Reset Attack Technique Observed in the Wild

On October 10, 2023, Google disclosed a previously unknown application-layer DDoS attack technique used by innovative attackers the company dubbed HTTP/2 “Rapid Reset.” The technique leverages a protocol vulnerability in the specification of the multiplexing feature in HTTP/2, allowing attackers to significantly increase the rate of their application-layer Web DDoS attacks. Google observed a series of DDoS attacks leveraging this new HTTP/2 Rapid Reset technique reaching peaks of up to 398 million requests per second (RPS), a 7.5x increase in attack rates compared to the previous record recorded by Google last year.

HTTP/2 Multiplexing

In HTTP/1.0, each TCP connection handles one request and response. HTTP/1.1, outlined in RFC2616, introduced pipelining. Though not commonly adopted, malicious actors have exploited this feature to boost the rate at which they can send requests over a single TLS session, aiming to overwhelm a web server or its backend infrastructure.

Although HTTP/1.1 pipelining allows a new request to be initiated even before the previous request receives a response, the responses will always be delivered in order. That means that a single large response, such as a download, can delay responses to requests with small responses made after the large request. This phenomenon is commonly referred to as head-of-line blocking.

HTTP/2, as defined in RFC7540, introduced a solution for the head-of-line blocking issue by implementing a new binary framing layer that encapsulates and transfers HTTP messages between client and server.

Figure 1: HTTP/2 binary framing layer (image: Ilya Grigorik* )

The TLS session between client and servers basically serves as a tunnel allowing multiple concurrent and independent streams to be transferred between client and server. Responses to requests are no longer guaranteed to be received in order and longer requests will not block the transmission of responses for smaller requests.

The head-of-line blocking is no concern to the attacker. Their goal is to flood the server with as many requests as possible in the shortest amount of time while keeping the request generation as efficient as possible, preferably without the need to receive and process too many responses from the server.

There is no maximum defined for the number of concurrent requests in the HTTP/1.1 RFC. Most HTTP implementations allow a configurable number between one and eight with a default setting of four. The setting of one means only one concurrent request can be outstanding a one specific moment, this basically disables pipelining. A maximum setting of eight will allow eight requests to be performed without having to wait for a response. The ninth request would then have to wait for the response to the first request to come in before it can be processed.

The RFC does not enforce a maximum number of streams in HTTP/2 multiplexing. It does, however, provide guidance for this number to not be smaller than 100—to not unnecessarily limit parallelism. This means that an attacker can generate up to 100 requests without having to wait for a single response from the server. After 100 requests, the attacker must wait for any of the responses to come back before starting a new request. HTTP/2 defines the support for a special “RST_STREAM” (aka reset stream) frame. RST_STREAM can be used by either client or server to request the cancellation of a particular stream (for example, after an error condition has occurred). RST_STREAM allows for the immediate termination of the identified stream.

An attack could queue a maximum of 100 requests, but if each new request stream is immediately followed by an RST_STREAM frame, the stream will be closed as soon as the server receives the frame, and the attacking client will be allowed to create new requests. The server will start processing the request, but it will not transmit the response once it’s available. It ignores the response because the stream was reset earlier by the client. By leveraging the RST_STREAM frame of the HTTP/2 protocol specification, an attacker can theoretically infinitely flood the server with new requests without having to create a new TLS session.

HTTP/1.1 pipelining allows a certain degree of concurrency, but the rate of requests over a single TLS connection will be regulated by the server’s capability to process and respond to the requests. To flood a server at the maximum rate, an attacker will need to create and tear down multiple TLS sessions. An HTTP/2 Rapid Reset attack, however, allows an attacker to theoretically flood a server with an infinite number of requests through a single TLS connection.

Impact

The HTTP/2 Rapid Reset attack targets application backends and in part the webserver’s ability to accept and process new requests. The request flood lives completely in the L7 application layer. Compared to TLS attacks, the web server will not have to process large amounts of TLS handshakes, but neither will the client, making the objective of the HTTP/2 Rapid Reset attack different from the known TCP exhaustion and TLS crypto processing overload attacks. The HTTP/2 Rapid Reset will also have limited impact on any L3/L4 network devices and TCP/IP stack implementations on systems since there is no TCP handshake for every single request as there would be in HTTP/1.0 attacks.

Mitigation

To be effective, rate-based attack mitigation needs to distinguish between legitimate and malicious requests. Network level rate limiting leveraging TCP connection limits, either per server or per source IP, can help keep a server alive but will still result in service degradation since malicious requests are not completely eliminated and will be processed by the service. Network rate limiting is only a partial solution against HTTP/1.0-based attacks—and to a lesser degree against HTTP/1.1 pipelining attacks. Network rate limiting is, however, not effective against HTTP/2 Rapid Reset attacks because the high-frequency request flows are embedded in streams implemented on top of a persistent TCP/TLS connection. Web application layer behavioral detection is the most effective solution against this new attack technique. Learn more on how to stay protected amidst the recent rise in Web DDoS attacks here.

CVE-2023-44487

Google led a coordinated vulnerability disclosure process and reserved CVE-2023-44487 to track potential fixes to HTTP/2 implementations.

Conclusion

The HTTP/2 Rapid Reset attack technique is yet another weapon in the growing arsenal of application-level attack techniques available to malicious actors aiming to disrupt online businesses.

* Image (C) Ilya Grigorik. Published by O’Reilly Media, Inc. Licensed under CC BY-NC-ND 4.0.