I’m thrilled to sit down with Dominic Jainy, a renowned IT professional whose expertise spans artificial intelligence, machine learning, and blockchain. Today, however, we’re diving into his insights on cybersecurity, specifically focusing on a critical vulnerability in the HTTP/2 protocol known as MadeYouReset. With his deep understanding of emerging technologies and their implications, Dominic is the perfect guide to help us unpack how this flaw enables massive distributed denial-of-service (DDoS) attacks, the challenges in addressing it, and what it means for the future of internet security. Our conversation explores the technical nuances of HTTP/2, the evolution of attack techniques, and the ongoing efforts to safeguard web infrastructure.
Can you start by walking us through what the HTTP/2 protocol is and why it plays such a vital role in how the internet functions today?
Absolutely. HTTP/2 is the second major version of the Hypertext Transfer Protocol, which is the foundation of data communication on the web. Introduced in 2015, it was designed to make websites load faster and handle traffic more efficiently than its predecessor, HTTP/1.1. It’s crucial today because it supports modern web experiences—think streaming, interactive apps, and heavy multimedia content—by allowing multiple data streams to be processed simultaneously over a single connection. This capability is a game-changer for performance, especially with the massive volume of internet traffic we see now, powering everything from e-commerce to social media platforms.
What sets HTTP/2 apart from HTTP/1.1, particularly when it comes to managing multiple requests at the same time?
The big difference is in how HTTP/2 handles concurrency. With HTTP/1.1, a browser and server had to process one request and response at a time before moving to the next, which created bottlenecks, especially on complex sites with lots of images or scripts. HTTP/2 introduces multiplexing, meaning it can send and receive multiple requests and responses simultaneously over one connection using data streams. This cuts down on latency and speeds things up significantly. However, to prevent abuse, like overwhelming a server, HTTP/2 has limits on the number of concurrent streams—often set to a default of 100—which attackers have unfortunately found ways to exploit.
Let’s talk about the Rapid Reset attack from 2023. How did it exploit HTTP/2’s design, and what kind of damage did it cause?
The Rapid Reset attack, identified in 2023, was a clever manipulation of HTTP/2’s stream management. Attackers would send a flurry of requests to a server and immediately cancel them, signaling to the protocol that those streams were free for new requests. But here’s the catch: while the HTTP/2 layer thought the stream was done, the server’s backend often kept processing the canceled requests, eating up resources. This allowed attackers to flood servers with endless requests, leading to the largest DDoS attack recorded at the time. It overwhelmed major online services, disrupting access for countless users and exposing a fundamental flaw in how HTTP/2 implementations handled cancellations.
After Rapid Reset was patched, researchers developed a new technique called MadeYouReset. How did they come up with this, and what makes it different?
Once Rapid Reset was mitigated by limiting how often clients could cancel requests, researchers at Tel Aviv University started probing for other weaknesses in HTTP/2. They discovered MadeYouReset, a technique that flips the script. Instead of the client canceling streams, it tricks the server into doing it. By sending a valid request followed by an invalid control message, attackers force the server to cancel the stream on its own. This bypasses the Rapid Reset fix because the cancellation isn’t coming from the client, yet it achieves the same effect of overloading the server with minimal effort from the attacker.
Can you explain how MadeYouReset manipulates servers into canceling streams, and what part control frames play in this process?
Sure. In HTTP/2, communication happens through frames—some carry regular web content, while others, called control frames, manage how streams behave, like setting parameters or signaling issues. With MadeYouReset, an attacker starts with a legitimate request to open a stream. Then, they send an invalid control frame, which violates the protocol’s rules. The server, detecting this error, cancels the stream itself to maintain integrity. This cancellation frees up a slot for a new stream, just like in Rapid Reset, allowing the attacker to repeat the cycle endlessly. It’s a sneaky way to exploit the server’s own protective mechanisms against it.
Why is MadeYouReset rated as just as dangerous as Rapid Reset, with a similarly high score on the vulnerability scale?
MadeYouReset earned a high 7.5 rating on the CVSS scale, matching Rapid Reset, because it poses a comparable threat. It enables attackers to launch massive DDoS attacks by exhausting server resources with repeated stream cancellations, all while evading the fixes put in place for Rapid Reset. The potential scale is enormous—potentially affecting up to a third of websites worldwide. Its severity comes from how easily it can be executed and the difficulty in fully mitigating it across diverse HTTP/2 implementations, making it a critical risk for internet infrastructure.
How widespread is the risk from MadeYouReset, and why is it tough to pin down the exact number of vulnerable systems?
The scope is massive, with estimates suggesting up to one-third of all websites could be at risk, though exact numbers are elusive. This uncertainty stems from the sheer diversity of HTTP/2 implementations across servers, frameworks, and vendors. Not every system reports or tracks its configuration publicly, and many use custom or layered setups where vulnerabilities might hide. Plus, while some vendors were already protected or patched quickly, others are still assessing or debating responsibility, leaving a patchwork of exposure that’s hard to quantify comprehensively.
What steps did the researchers from Tel Aviv University take to inform vendors about MadeYouReset, and how did the response vary across companies?
The team at Tel Aviv University took a responsible disclosure approach, reaching out to over 100 vendors to warn them about MadeYouReset before making it public. Responses varied widely. Some vendors acknowledged the issue immediately and committed to fixes, while others had already fortified their systems after Rapid Reset with broader stream management improvements. However, there were also companies who saw the problem but argued it wasn’t their responsibility to address, often pointing fingers between HTTP/2 library developers and server operators. This inconsistency shows how complex the ecosystem is when it comes to coordinated defense.
Some vendors were immune to MadeYouReset even before it was disclosed. What kinds of proactive measures had they taken?
Vendors who were already protected had learned from Rapid Reset and implemented deeper changes to how they manage resources and streams. For instance, they enhanced their systems to better track and limit overall stream activity, not just client-initiated cancellations. Some introduced stricter resource allocation rules to prevent servers from overcommitting to canceled requests. Companies like Cloudflare noted that many modern HTTP/2 setups fell into this category, having adopted robust stream and memory management practices that inadvertently blocked MadeYouReset’s attack vector right out of the gate.
For vendors who weren’t prepared, what are some strategies they’ve used or could use to defend against MadeYouReset attacks?
Vendors who needed to respond have explored a few approaches. One is to ensure that when a stream is canceled—whether by client or server—all associated backend work stops immediately, though that’s technically challenging. Another is setting custom limits on server-initiated cancellations, mirroring the client-side limits from Rapid Reset fixes. Some have also built additional request throttling at the server level to compensate for protocol weaknesses. Each solution depends on the specific HTTP/2 setup, but the goal is to prevent attackers from exploiting cancellations to overload resources.
Why is stopping backend work on a canceled stream so challenging, and what potential dangers come with interrupting those processes?
Halting backend work on a canceled stream sounds simple, but it’s a logistical nightmare. Backend systems often operate independently of the HTTP/2 protocol layer, so syncing them to instantly stop processing isn’t always feasible without major redesigns. You’ve got databases, application logic, and other services that might already be mid-task—interrupting them can cause data inconsistencies or crashes. Plus, abruptly stopping operations risks introducing new vulnerabilities, like leaving half-processed requests in a state that attackers could exploit. It’s a delicate balance between efficiency and security.
There’s been disagreement among vendors about whether the HTTP/2 library or the server itself should handle the fix. Can you unpack why this debate exists and how it impacts solutions?
This debate boils down to the layered nature of web systems. HTTP/2 libraries handle protocol rules, like stream management, while servers manage the actual workload and resource allocation. MadeYouReset can theoretically be fixed at either layer—libraries could limit server cancellations, or servers could enforce stricter request handling. When vendors use external libraries, it gets murky: who’s accountable? This philosophical tug-of-war slows down solutions because it delays consensus on where patches should live, potentially leaving systems exposed longer while the discussion drags on.
Are there particular HTTP/2 implementations that stand out as more vulnerable to MadeYouReset, and what makes them concerning?
Yes, certain implementations like Netty, Apache Tomcat, and Jetty have been flagged as more at risk, with varying severity ratings. For example, Netty has a higher CVSS score of 8.2 for this issue due to how its framework handles stream cancellations, making it easier to exploit. These systems are widely used in enterprise environments, so a vulnerability here impacts a lot of critical infrastructure. The concern is amplified because not all users of these frameworks update promptly, and custom configurations can sometimes weaken built-in protections.
What immediate actions can website owners or server admins take to shield themselves from MadeYouReset if their vendor hasn’t rolled out a fix yet?
For those still waiting on vendor patches, there are some practical steps. First, monitor traffic for unusual patterns, like a spike in canceled streams, and consider rate-limiting incoming requests as a temporary shield. If possible, tweak server settings to lower the maximum concurrent streams below the default, reducing the attack surface. Also, check if your HTTP/2 implementation allows custom cancellation limits and apply them. It’s not foolproof, but these measures can buy time. Staying in touch with your vendor for updates is critical too.
Looking to the future, what’s your forecast for the security of HTTP/2 and similar web protocols in light of evolving attack techniques like MadeYouReset?
I think HTTP/2’s security will remain a moving target. As protocols evolve to handle more complex, high-speed web demands, attackers will keep finding creative ways to exploit features like stream multiplexing. MadeYouReset shows that even fixes can be bypassed with enough ingenuity. My forecast is that we’ll see a push toward more adaptive, layered defenses—think AI-driven anomaly detection and stricter protocol standards. But it’ll require unprecedented collaboration among vendors, developers, and researchers to stay ahead. We’re in for a long game of cat and mouse, and the stakes are only going to get higher as the internet grows.