10 ms·
HAProxy is not affected by the HTTP/2 Rapid Reset Attack
- tick_tock_tick 3y ago[flagged]
- altairprime 3y agohaproxy mitigated this attack in 2018 as an implementation bug: https://news.ycombinator.com/item?id=37833365 https://news.ycombinator.com/item?id=37833365
- tick_tock_tick 3y agoThat would have been wonderful context for them to include.
- donutshop 3y agoWhoa. So they're 5 years ahead of everyone else?
- notRobot 3y ago> After rigorous testing, we have been able to confirm that our implementation of the HTTP/2 protocol can handle the Rapid Reset Attack without increasing the resource usage or compromising the parallelism of the protocol. You are free to conduct your own tests? AFAIK the software in question is free (both libre and commercially).
- toast0 3y agoIf you want lots of details, this specific post on the mailing list is there https://www.mail-archive.com/haproxy@formilux.org/msg44136.html https://www.mail-archive.com/haproxy@formilux.org/msg44136.h...
- KomoD 3y ago> make anyone else think they just failed to properly test/verify their claim? Nope, not me.
- stygiansonic 3y agoAfter rigorous testing, we have been able to confirm that our implementation of the HTTP/2 protocol can handle the Rapid Reset Attack without increasing the resource usage or compromising the parallelism of the protocol. But doesn’t this mean the servers behind the reverse proxy would still suffer from increased/wasted resources responding to the rapid reset requests?
- lillecarl 3y agoIf you're doing tcp load balancing sure, but http is terminated at the proxy and wouldn't be vulnerable. This is why you put $proxy or $webbserver in front of your application webserver.
- crote 3y agoNot by definition. Looking at Cloudflare's summary of the attack[0], part of it seems to rely on sending a request and then cancelling it in the very same packet. A trivial implementation might walk through the packet front-to-back, firing off requests and cancellations immediately as it encounters them. That would indeed still result in a lot of load on the servers behind the proxy. However, a reasonable alternative would be to only collect a set of actions to execute while walking through the packet, firing them off all at once when you finish. For example, a "launch request" could create a new entry in the backend requests list with a state of "NEW". The "cancel request" part immediately afterwards could then look in the backend request list and set the state of the corresponding request to "CANCEL". Now when the backend request list is being processed next, it'll only see a request marked "CANCEL" without a corresponding socket to a backend, shrug, and just delete the entry because there is nothing to do. [0]: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ https://blog.cloudflare.com/technical-breakdown-http2-rapid-...
- dylan604 3y agoI thought you were going to suggest it to be processed like one of those trick exams of reading all of the questions before answering any of the questions where the last question is something so obvious that like stand up sit down, then turn in the test with out writing anything on it. So in this case, read all of the instructions in the packet. If the last is CANCEL, do nothing.
- tpmx 3y agoI'm quite impressed with HAProxy. It takes a little effort to fully understand the configuration file format (hint: you've got to read the documentation, not just look at examples to fully grok it), but it's so worth it, IMO. It's also a nice treat to have the founder and technical leader (Willy Tarreau) of the HAProxy company being so active in the community, so many years later (the initital release was in 2001). I regularly see him answering e.g. newbie questions. (HAProxy docs: https://docs.haproxy.org/ https://docs.haproxy.org/ - pick 2.8/LTS)
- exabrial 3y agoIt's become my swiss army knife of TCP. I nearly always terminate TCP first with haproxy "out of process" of whatever, then have it proxy over a unix socket to "whatever". This allows an immense amount of flexibility, from being able to "wiretap" whats going on in the real world, to default error pages, alarms, monitoring, handling CORS... tons of uses.
- tpmx 3y agoPlease write a blog post about this and submit it to HN!
- scns 3y agoThat is some very well written documentation IMHO.
- chasingtheflow 3y agoCan’t seem to read it on mobile.
- rrrix1 3y agoYou probably don't want to. Usually it needs at least a browser window, an editor and maybe an open TTY. haproxy.cfg can be ... tricky.
- deleted 3y ago[deleted]
- chatmasta 3y agoMore details [0] about the mitigation are discussed on the mailing list: > So at first glance we indeed addressed this case in 2018 (1.9-dev) with this commit: > f210191dc ("BUG/MEDIUM: h2: don't accept new streams if conn_streams are still in excess") > It was incomplete by then an later refined, but the idea is there. But I'll try to stress that area again to see. [0] https://www.mail-archive.com/haproxy@formilux.org/msg44134.html https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...
- jedberg 3y agoNot all surprised by this, HaProxy is some of the best built software I've ever seen. But glad to know they checked.
- beachy 3y agoWondering if anyone knows the exposure when using an nginx proxy?
- merlincorey 3y agoThis is news because of an exploit found against NginX, I believe. That's why HAProxy did testing to see if they were vulnerable.
- fragmede 3y agoThis is news because of a massive DDoS against AWS/Cloudflare/Google, and isn't related to a particular flaw in NginX https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack https://cloud.google.com/blog/products/identity-security/how...
- el_duderino 3y agohttps://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...