HTTP/2 Rapid Reset DDoS Attack

http2-rapid-reset-ddos-attack.md

Introduction

This Gist aims to centralise the most relevant public sources of information related to the HTTP/2 Rapid Reset vulnerability. This vulnerability has been disclosed jointly by Google, Amazon AWS, and Cloudflare on 10 October 2023 at 12:00 UTC.

Please help us make this page as comprehensive as possible by contributing relevant references, vendor advisories and statements, mitigations, etc.

References

• CVE-2023-44487, CIRCL CVE Search
• How AWS protects customers from DDoS events, AWS
• How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack, Google
• HTTP/2 Rapid Reset: deconstructing the record-breaking attack, Cloudflare
• Microsoft Response to Distributed Denial of Service (DDoS) Attacks against HTTP/2, Microsoft
• Potential mention of a similar issue in 2018 concerning HAproxy
• RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
• Security Advisory 2023-074 HTTP/2 Rapid Reset DDoS Vulnerability, CERT-EU
• HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487, CISA
• Using HTTP/3 Stream Limits in HTTP/2 - IETF draft to backport the HTTP/3 steam limits in HTTP/2

Vendor advisories and statements

• Apache Tomcat - Fixed in 8.5.94
• AWS
• F5
• Golang
• HAPROXY - HAProxy is not affected by the HTTP/2 Rapid Reset Attack
• Kong
• Microsoft IIS
• Microsoft MsQuic - Fixed in 2.2.3
• Netscaler
• Nginx
• nghttp2 library - Fixed in 1.57.0

Testing if HTTP/2 is enabled

OpenSSL

echo 1 | openssl s_client -alpn h2 -connect google.com:443 -status 2>&1  | grep "ALPN"

Nmap

nmap -p 443 --script=tls-nextprotoneg www.google.com

curl

curl -Is --http2-prior-knowledge https://example.com/| head -1

Testing if it's vulnerable (use at your own risk)

• Basic vulnerability scanning tool to see if web servers may be vulnerable to CVE-2023-44487
• Rapid Reset Client is a tool for testing mitigations and exposure to CVE-2023-44487 (Rapid Reset DDoS attack vector)

Potential remediation

NGINX

can be configured to mitigate the vulnerability

• Disabling HTTP/2 in NGINX is not necessary. Simply ensure you have configured:

  • keepalive_requests should be kept at the default setting of 1000 requests
  • http2_max_concurrent_streams should be kept at the default setting of 128 streams
  • limit_conn and limit_req should be set "with a reasonable setting balancing application performance and security"

If you want to remove http2 support

• Remove reference to http2 in the listening part

DDoS protection / CDNs

Web apps that are behind the following DDoS protection providers / CDNs should not be impacted:

• AWS
• Cloudflare
• Google Cloud
• Microsoft Azure

NGINX mitigation: please note the nginx.com blog has been updated to separate essential configuration from recommended.

Testing if HTTP/2 is enabled with curl(1)

curl -Is --http2-prior-knowledge https://example.com/| head -1

@lcrilly Thank you. it’s updated.

@ravager-dk Thank you it’s updated.

I wrote a tool that implements a sparse HTTP/2 client and emulates this attack. It can be used to test system behavior to rapid HEADERS + RST_STREAM frames.

@secengjeff Thank you. It's included.

Kong has a blog post too:

https://konghq.com/blog/product-releases/novel-http2-rapid-reset-ddos-vulnerability-update

@crstian19 Thank you it's updated.

Apache Tomcat apache/tomcat@9cdfe25 was backported to the released 11.1.14. However, this version had a regression. So, it is better to use 11.1.15

Hello, besides this information is there any public datasets related to this attacks? Im currently doing research about the topic and would be very useful to check traffic generated by this kind of attack. Thank you in advance.

Thanks you for docs. it's lightspeed rapid reset blog.
https://blog.litespeedtech.com/2023/10/11/rapid-reset-http-2-vulnerablilty/