HTTP/2 Rapid Reset: deconstructing the record-breaking attack | Hacker News Reader

HTTP/2 Rapid Reset: deconstructing the record-breaking attack

blog.cloudflare.com

108 pointstodsacerdoti23 comments

Perhaps off topic, but I can’t help but feel, since this is the 3rd HN topic I’ve seen on this, that all of this publicity about how “record-breaking” this attack is will only drive more attempts to break said record. People love notoriety.

Has there been any indication of who was behind the attack? Notoriety usually requires knowing who was responsible first.

But at this scale, I doubt someone is trying to do this just for the fun of it.

For those interested in more on the same topic, there is a decent list of blogs at the end of this:

https://www.cve.org/CVERecord?id=CVE-2023-44487

(and yes, that includes this article here as well).

If I run a nginx without Cloudflare, what should I do?

There is a commit that just landed on github so I assume there is a release out (or out soon).

https://github.com/nginx/nginx/commit/6ceef192e7af1c507826ac...

It seems strange that there are no test cases for this. Is that normal from nginx? And committed straight to master with no PR - is this a mirror from somewhere else, or the official repository?

Edit: seems it is a mirror from http://hg.nginx.org/nginx/

Read this: https://mailman.nginx.org/pipermail/nginx-devel/2023-October...

Does anyone have details about what clients don't respect the maximum stream concurrency limit? I threw together a quick test and it seems to be working for me. The test is a page with 100 images using a host configured with a maximum of 4 concurrent streams.

I don’t have an answer, but the article’s description made it sound like clients assume a default of 100 until it received the sever’s value in a SETTINGS frame. So there would only be a brief window of time where the client would appear to not respect the server’s configuration. I would assume the SETTINGS are pretty quick to be sent.

Conjecture on my part but their example of a photo album loading 100 images at once might come up where the page html/js/css are served up from one domain and the resulting page immediately tried to load images from a separate content server which has the lower limit. Maybe try updating your test to use two servers, one that serves up a page with 100 img tags, all different img resources being loaded from the second server, and the second server has the low concurrency limit. That might result in the browser issuing 100 immediate requests to server 2 without awaiting the SETTINGS frame.

Given that the entire web typically sees only between 1–3 billion requests per second - any data to back that up?

Unable to download pcap "Download the pcap to follow along." When going to the page it gives the error "Not found"

Am I the only one alarmed with this sentence: “… when a client connects to Cloudflare to send HTTPS traffic, it first hits our TLS decryption proxy: it decrypts TLS traffic, processes HTTP 1, 2 or 3 traffic, then forwards it to our "business logic" proxy.”

I’m not a specialist in networking, but isn’t the only thing that should be decrypting TLS traffic, is the entity I’m sending data to or my browser?

The entity you are sending data to is Cloudflare

HTTP/2 multiplexing occurs inside the TLS boundary - there isn't a separate TLS stream for each sub-request. To demultiplex the requests you have to decrypt them first.

Cloudflare doesn't cost money, you pay the price with your soul.

That's just how cloudflare works. It can't know what to cache, or use any rules based on the http request without decrypting the traffic. And without decrypting the request it can't do any application layer DDoS prevention.

When you use cloudflare, or any other CDN, you either give them a certificate for your domain, or use DNS to allow them to acquire a certificate on your behalf.

What about it alarms you? Given the service they’re offering, what do you expect them to do instead?

All non hipaa services decrypt at the edge. It's more efficient and easier to manage.

So basically HTTP/2 authors missed the existence of TCP SYN-flood attacks(Not the same, but more or less the same mechanism)? Was this bought up during standardization meetings or was it just hubris?

https://en.wikipedia.org/wiki/SYN_flood

As did attackers, how many years has http/2 been around?

When HTTP/2 came out attackers where busy exploiting every point in the security advisory section of the RFC. Over night a large amount of web services where suddenly vulnerable to de-sync attacks.

Nope, this looks like it's about opening streams (with related work) and closing them in rapid succession, over an established connection.

Reply on news.ycombinator.com