Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2 rapid reset attack impacting Nginx products

nginx.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: HTTP/2 rapid reset attack impacting Nginx products

#31

Post by gshulegaard »

nimbius wrote: post #27

FYI this is for the commercial nginx product, hastily purchased by F5 a few years back when software load balancers were annihilating their hardware offering. Curious to see f5 still playing games with their own cve disclosure on the bigip product though...assigning it a mitre cw400 is just lying. https://my.f5.com/manage/s/article/K000137106

Both http2_max_concurrent_streams and keepalive_requests (the configuration parameters discussed in this article) are configuration parameters available in open source nginx:

http://nginx.org/en/docs/http/ngx_http_v2_module.html#http2_...

http://nginx.org/en/docs/http/ngx_http_core_module.html#keep...

So are limit_conn and limit_req:

https://nginx.org/en/docs/http/ngx_http_limit_conn_module.ht...

https://nginx.org/en/docs/http/ngx_http_limit_req_module.htm...

So it pertains to both NGINX and NGINX+.

Re: HTTP/2 rapid reset attack impacting Nginx products

#32

Post by gear54rus »

1vuio0pswjnm7 wrote: post #28

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…

Well you ain't getting no-JS webpages because it's too useful so maybe HTTP/2 in the end? Adblock helps with ad I hear.

Re: HTTP/2 rapid reset attack impacting Nginx products

#33

Post by jchw »

dang wrote: post #2

Related. Others? HAProxy is not affected by the HTTP/2 Rapid Reset Attack - https://news.ycombinator.com/item?id=37837043 - Oct 2023 (31 comments) The largest DDoS attack to date, peaking above 398M rps - https://news.ycombinator.com/item?id=37831062 - Oct 2023 (461 comments) HTTP/2 Rapid Reset: deconstructing the record-breaking attack - https://news.ycombinator.com/item?id=37831004 - Oct 2023 (22 comments) HTTP/2 z…

I don't know if a post to HN has been made (don't think so), but Envoy released 1.27.1 in response to Rapid Reset as well.

https://www.envoyproxy.io/docs/envoy/v1.27.1/version_history...

Re: HTTP/2 rapid reset attack impacting Nginx products

#34

Post by kelthan »

ComputerGuru wrote: post #26

I’m stuck trying to figure out if this is technically desired behavior or not. If you were retroactively designing http/2 with this knowledge, would you have done anything different?

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 specifications in which those gaps are not even possible.

Modern software systems are some of the most complex systems that humans have ever invented--and they just keep getting more complex over time as we layer new things on top of them. Think of a really high Jenga tower with lots of holes in the base.

That means we need to strive to keep things simple. That may mean making decisions that prevent common or severely impacting failure cases from being possible, even if it is a little more difficult to do, or eliminates an esoteric use-case. This is even more true when writing specifications that others will implement and/or be expected to conform to.

Re: HTTP/2 rapid reset attack impacting Nginx products

#35

Post by kelthan »

MallocVoidstar wrote: post #22
andrewstuart wrote: post #21

Anyone know if it affects Caddy?

Patched in 2.7.5: https://github.com/caddyserver/caddy/releases/tag/v2.7.5 I think it might also require a patched version of Go.

There are new versions of Go which have this CVE patched already published and available for download.

Re: HTTP/2 rapid reset attack impacting Nginx products

#37

Post by veeti »

1vuio0pswjnm7 wrote: post #28

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…

HTTP2 Server Push has been deprecated already https://developer.chrome.com/blog/removing-push/

Re: HTTP/2 rapid reset attack impacting Nginx products

#38

Post by j16sdiz »

kelthan wrote: post #34
ComputerGuru wrote: post #26

I’m stuck trying to figure out if this is technically desired behavior or not. If you were retroactively designing http/2 with this knowledge, would you have done anything different?

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 to throttle without user-visible error.
 
  4. The client can cancel any request mid-flight (removing this is equally bad, security-wise)
Unless you are removing the concurrency, making the protocol simpler won't fix it.

The protocol designer need adversary mindset, not a simpler mind

Re: HTTP/2 rapid reset attack impacting Nginx products

#39

Post by jprd »

MallocVoidstar wrote: post #22
andrewstuart wrote: post #21

Anyone know if it affects Caddy?

Patched in 2.7.5: https://github.com/caddyserver/caddy/releases/tag/v2.7.5 I think it might also require a patched version of Go.

You could 'caddy upgrade' pretty quickly to get the patch (servers had updated go), though the release number bump didn't happen immediately.

Running the same now, or pulling a new binary, using xcaddy, etc. will get you 2.7.5 which also includes some other small fixes not related to rapid reset.

Re: HTTP/2 rapid reset attack impacting Nginx products

#40

Post by k_roy »

codetrotter wrote: post #9
herpderperator wrote: post #6

Earlier quoted context omitted.

If you read the article, you'll see that the default configuration is not affected.

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.

Post reply on HN