Anyone know if it affects Caddy?
HTTP/2 rapid reset attack impacting Nginx products
21–30 of 66 posts
Re: HTTP/2 rapid reset attack impacting Nginx products
#22Anyone 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.
Re: HTTP/2 rapid reset attack impacting Nginx products
#23Earlier quoted context omitted.
CVEs aren't restricted to only consider default configs.
There is a difference between an application being innately vulnerable and a user configuration exposing a vulnerability. Interestingly enough, HAProxy seems to have the same mitigation: > Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack. http…
I think the important distinction is ‘a user may plausibly have this non default configure’ vs ‘this config is obscure almost nobody will be running it this way’
Re: HTTP/2 rapid reset attack impacting Nginx products
#24Related. 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 posted another one the other day which didn't get any traction but probably goes in the list: https://news.ycombinator.com/item?id=37835295
Re: HTTP/2 rapid reset attack impacting Nginx products
#25From some first-hand experience over the last few months… these suggestions and patch will help prevent a single client from overwhelming an NGINX server, but it will do little to stop even a modest botnet from generating enough requests to be a problem. Keeping some state on IPs and downgrading those that exceed limits to HTTP/1.1 I believe is the only effective defense. Tuning those thresholds to get them right is……
If the only viable fix is to downgrade clients to an earlier protocol, do you take that to mean that there is a fundamental weakness in the protocol itself?
Re: HTTP/2 rapid reset attack impacting Nginx products
#26I’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?
Re: HTTP/2 rapid reset attack impacting Nginx products
#27FYI 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.
Re: HTTP/2 rapid reset attack impacting Nginx products
#28If 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 do not auto-load resources, run Javascript nor carry out "server push". Works great for me. Web is not slow.
According to HTTP/2 proponents, the protocol originated at an online advertising services company and was developed by companies that profit from sale and delivery of online advertising, HTTP/2 was designed to "speed up the web".
I respect that opinions on HTTP/2 may differ. If someone loves HTTP/2, then I respect that opinion. In return I ask that others respect opinions that may differ from their own, including mine. NB. This comment speaks only for the web user submitting it. It does not speak for other web users. IMHO, no HN commenter can speak for other web users either. Thank you.
Re: HTTP/2 rapid reset attack impacting Nginx products
#29If 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 would say that a text-only experience is valid I don't think it's how the majority of people want to use the web. Users want a rich multimedia experience.
If HTTP/2 speeds up a rich multimedia web experience then it may legitimately be one way to "speed up the web" for someone who expects that level of experience.
I don't think it's fair to criticize a protocol for who designed it. The specification is out there for anyone to interpret and if there is specific complaint in it's design then make that.
Re: HTTP/2 rapid reset attack impacting Nginx products
#30Earlier quoted context omitted.
There is a difference between an application being innately vulnerable and a user configuration exposing a vulnerability. Interestingly enough, HAProxy seems to have the same mitigation: > Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack. http…
I think the important distinction is ‘a user may plausibly have this non default configure’ vs ‘this config is obscure almost nobody will be running it this way’
I am not sure I understand how stream limit configuration between two L4/L7 load balancers is meaningfully different. In my mind, either the configuration of stream limits is a vulnerability for all L4/L7 load balancers that offer that configuration or it's not for all of them.
If one doesn't _offer_ configuration of stream limits and therefore is not susceptible to user misconfiguration, then I would get the distinction. But as I understand it both HAProxy and NGINX have the same configuration options which _could_ be vulnerable if configured poorly by the user. One is just putting a lot more positive spin on it.