Live data from Hacker News

HTTP/2 rapid reset attack impacting Nginx products

nginx.com

41–50 of 66 posts

Re: HTTP/2 rapid reset attack impacting Nginx products

#41
post #12

Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack followed by the name of Nginx. I didn’t find anything relevant so I assumed that Nginx was not affected. Turns out that was not a good assumption :p

I immediately thought I’m happy not having to operate anything with nginx in front of it.

So you are operating every other product that was impacted by this?

This headline is pretty misleading as the article outlines you would need a fairly non-standard config to be exploited like this.

Versus many other products that the stock configs are vulnerable.

Re: HTTP/2 rapid reset attack impacting Nginx products

#42

Why the submission OP? Lots of discussion and submissions related to this over the last few days, not to mention this submitted 2 days ago

Because Nginx is a very widespread high performance web server that initially seemed not to be impacted but now it turns out that it is.

Except it's only impacted in a pretty non-standard config.

Not that it's not important to disseminate the knowledge, but the chosen title here is deliberatley sensational

Re: HTTP/2 rapid reset attack impacting Nginx products

#43
post #38
post #34

Earlier quoted context omitted.

Yes, because it's exploitable. Systems that require very high cognitive load on their human operators (whether machines, programming languages, etc.) are alway destined to fail. Human beings are not good at doing boring, repetitious work that requires them to stay focused: lapses will occur. And hackers are going to find and exploit those gaps. So the best way to avoid those problems is to build solutions or specific…

I guess the parent post want to know if there are any _specific_ and _effective_ change for this kind of attacks. In this case, simplifying the protocol won't help -- the vulnerability is: 1. Backend servers can't cancel immediately (this is no protocol problem) 2. The client can make concurrent request in a connection (This is the goal of Http/2) 3. The concurrency is pre determined, there is no way for the server t…

You should be able to cancel a request, but you don't get it back (as in, can't send another) until the server acks the cancel.

Re: HTTP/2 rapid reset attack impacting Nginx products

#44
post #40

Earlier quoted context omitted.

I know. But not everyone uses the default configuration.

the article literally points out the somewhat rare configuration you would have to have to be exploited by this. The way this headline is worded is pretty misleading, and you clearly sucked it up.

Here’s the thing. I use Nginx. Some of the configurations in which I use Nginx were mostly copy-pasted from recommendations from third-parties. Hence, my initial assumption which had been that no action was needed when I didn’t find anything mentioning Nginx with this attack when I searched a few days ago, needed to be revisited.

Because when I saw the op article it turned out that there was reason for me to have a closer look at my Nginx instances. To see if any of the configs that had been recommended by third-parties involved changing values that could lead to this attack being able to affect me.

> you clearly sucked it up

Clearly not. Or at least, not without reason.

Re: HTTP/2 rapid reset attack impacting Nginx products

#45

Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack followed by the name of Nginx. I didn’t find anything relevant so I assumed that Nginx was not affected. Turns out that was not a good assumption :p

I did the same search a couple days ago with Duck, and this blog entry was the first or among the first results.

Re: HTTP/2 rapid reset attack impacting Nginx products

#48

If someone asked me how to "speed up the web", I would not suggest "use HTTP/2". I would remove ads and other garbage. As a decades long non-popular browser and TCP client user, I can testify this works very effectively. I prefer to have full control over the resources that I request, whether text or binary, so no auto-loading resources, no Javascript-requested resources and no HTTP/2 "server push". The clients I use…

I work in adtech and I haven't heard anybody in the industry push for HTTP/2.

It's still HTTP/1.1 everywhere here.

Re: HTTP/2 rapid reset attack impacting Nginx products

#49

If someone asked me how to "speed up the web", I would not suggest "use HTTP/2". I would remove ads and other garbage. As a decades long non-popular browser and TCP client user, I can testify this works very effectively. I prefer to have full control over the resources that I request, whether text or binary, so no auto-loading resources, no Javascript-requested resources and no HTTP/2 "server push". The clients I use…

HTTP/3 is now the version to upgrade to. We're in Google cloud so we've been running that for some time now without issues. Works great actually.

I don't get all this anti HTTP 2 & 3 sentiment on hacker news. What's wrong with people here? HTTP 1.1 is a quarter century old at this point. This sounds just like a bunch of grumpy old men arguing against progress. Time to move on. Yes HTTP/1.1 works. But it's also a bit limited and slow in various ways that both new HTTP variants address. One little bug in nginx is not going to change anything. Bugs happen all the time. They get fixed and people move on. I'm not hearing a lot of rational arguments here.

Re: HTTP/2 rapid reset attack impacting Nginx products

#50
post #42

Earlier quoted context omitted.

Because Nginx is a very widespread high performance web server that initially seemed not to be impacted but now it turns out that it is.

Except it's only impacted in a pretty non-standard config. Not that it's not important to disseminate the knowledge, but the chosen title here is deliberatley sensational

It impacts the product, there is nothing sensational about that. If it wasn't impacted that's what they would have said and with Nginx being the tool of choice for many high volume installations you can bet that there are many thousands running in non-standard configs.
Post reply on HN