HTTP/2 Rapid Reset: A New Protocol Vulnerability Will Haunt the Web for Years

Google, Amazon, Microsoft, and Cloudflare revealed this week that they battled massive, record-setting distributed denial of service attacks against their cloud infrastructure in August and September. DDoS attacks, in which attackers attempt to overwhelm a service with junk traffic to bring it down, are a classic internet menace, and hackers are always developing new strategies to make them bigger or more effective. The recent attacks were particularly noteworthy, though, because hackers generated them by exploiting a vulnerability in a foundational web protocol. This means that while patching efforts are well underway, fixes will need to essentially reach every web server globally before these attacks can be fully stamped out.

Dubbed “HTTP/2 Rapid Reset,” the vulnerability can only be exploited for denial of service—it doesn’t allow attackers to remotely take over a server or exfiltrate data. But an attack doesn’t need to be fancy to cause major problems—availability is vital for access to any digital service, from critical infrastructure to crucial information.

“DDoS attacks can have wide-ranging impacts to victim organizations, including loss of business and unavailability of mission-critical applications,” Google Cloud’s Emil Kiner and Tim April wrote this week. “Time to recover from DDoS attacks can stretch well beyond the end of an attack.”

Another facet of the situation is where the vulnerability came from. Rapid Reset isn’t in a particular piece of software but in the specification for the HTTP/2 network protocol used for loading webpages. Developed by the Internet Engineering Task Force (IETF), HTTP/2 has been around for about eight years and is the faster, more efficient successor to the classic internet protocol HTTP. HTTP/2 works better on mobile and uses less bandwidth, so it has been extremely widely adopted. IETF is currently developing HTTP/3.

“Because the attack abuses an underlying weakness in the HTTP/2 protocol, we believe any vendor that has implemented HTTP/2 will be subject to the attack,” Cloudflare’s Lucas Pardue and Julien Desgats wrote this week. Though it seems that there are a minority of implementations that are not impacted by Rapid Reset, Pardue and Desgats emphasize that the problem is broadly relevant to "every modern web server.”

Unlike a Windows bug that gets patched by Microsoft or a Safari bug that gets patched by Apple, a flaw in a protocol can’t be fixed by one central entity because each website implements the standard in its own way. When major cloud services and DDoS-defense providers create fixes for their services, it goes a long way toward protecting everyone who uses their infrastructure. But organizations and individuals running their own web servers need to work out their own protections.

Dan Lorenc, a longtime open source software researcher and CEO of the software supply chain security company ChainGuard, points out that the situation is an example of a time when the availability of open source and the prevalence of code reuse (versus always building everything from scratch) is an advantage, because many web servers have likely copied their HTTP/2 implementation from somewhere else rather than reinvent the wheel. If these projects are maintained, they will develop Rapid Reset fixes that can proliferate out to users.

It will take years to reach full adoption of these patches, though, and there will still be some services that did their own HTTP/2 implementation from scratch and don’t have a patch coming from anywhere else.

“It’s important to note that the big tech companies discovered this while it was being actively exploited,” Lorenc says. “It can be used to take a service down like operational tech or industrial control. That’s scary.”

Though the string of recent DDoS attacks on Google, Cloudflare, Microsoft, and Amazon raised the alarm for being so large, the companies were ultimately able to repel the attacks, which didn’t cause lasting damage. But just by carrying out the assaults, hackers revealed the existence of the protocol vulnerability and how it could be exploited—a cause and effect known in the security community as “burning a zero day.” Even though the patching process will take time, and some web servers will remain vulnerable long term, the internet is safer now than if attackers hadn’t shown their cards by exploiting the flaw.

“A bug like this in the standard is unusual, it’s a novel vulnerability and was a valuable finding for whoever first discovered it,” Lorenc says. “They could have saved it or even probably sold it for a lot of money. I’m always going to be curious about the mystery of why someone decided to burn this one.”