[HN Gopher] HAProxy is not affected by the HTTP/2 Rapid Reset At...
___________________________________________________________________
HAProxy is not affected by the HTTP/2 Rapid Reset Attack
Author : nickramirez
Score : 84 points
Date : 2023-10-10 20:29 UTC (2 hours ago)
(HTM) web link (www.haproxy.com)
(TXT) w3m dump (www.haproxy.com)
| abraae wrote:
| Wondering if anyone knows the exposure when using an nginx proxy?
| merlincorey wrote:
| This is news because of an exploit found against NginX, I
| believe.
|
| That's why HAProxy did testing to see if they were vulnerable.
| fragmede wrote:
| This 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...
| el_duderino wrote:
| https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...
| jedberg wrote:
| Not all surprised by this, HaProxy is some of the best built
| software I've ever seen. But glad to know they checked.
| tick_tock_tick wrote:
| Do posts like this that give zero justification why they are
| unaffected or any links to get a more detailed explanation make
| anyone else think they just failed to properly test/verify their
| claim?
| KomoD wrote:
| > make anyone else think they just failed to properly
| test/verify their claim?
|
| Nope, not me.
| notRobot wrote:
| > 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).
| altairprime wrote:
| haproxy mitigated this attack in 2018 as an implementation bug:
|
| https://news.ycombinator.com/item?id=37833365
| tick_tock_tick wrote:
| That would have been wonderful context for them to include.
| toast0 wrote:
| If you want lots of details, this specific post on the mailing
| list is there https://www.mail-
| archive.com/haproxy@formilux.org/msg44136.h...
| stygiansonic wrote:
| 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.
|
| But doesn't this mean the servers behind the reverse proxy would
| still suffer from increased/wasted resources responding to the
| rapid reset requests?
| crote wrote:
| Not 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-...
| dylan604 wrote:
| I 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.
| carlhjerpe wrote:
| If 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.
| tpmx wrote:
| I'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/ - pick 2.8/LTS)
| chaps wrote:
| Agreed. Haproxy is an absolute wonder compared to similar
| systems. It all just feels so much cleaner, thought out, and
| built from the ground up for many different use cases. It very
| much has a feel that reminds me a lot of the spirit of sqlite.
| tpmx wrote:
| Yeah. Stringency ( _marked by rigor, strictness, or severity
| especially with regard to rule or standard_ ) is a word that
| comes to mind.
| chatmasta wrote:
| More 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.h...
___________________________________________________________________
(page generated 2023-10-10 23:00 UTC)