Wondering if anyone knows the exposure when using an nginx proxy?
HAProxy is not affected by the HTTP/2 Rapid Reset Attack
11–20 of 36 posts
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#12After 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?
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-...
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#13Wondering if anyone knows the exposure when using an nginx proxy?
This is news because of an exploit found against NginX, I believe.
That's why HAProxy did testing to see if they were vulnerable.
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#14After 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?
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…
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.
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#15[flagged]
> make anyone else think they just failed to properly test/verify their claim?
Nope, not me.
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#16Wondering if anyone knows the exposure when using an nginx proxy?
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#17Wondering if anyone knows the exposure when using an nginx proxy?
This is news because of an exploit found against NginX, I believe. That's why HAProxy did testing to see if they were vulnerable.
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...
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#18I'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…
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.
Re: HAProxy is not affected by the HTTP/2 Rapid Reset Attack
#19I'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…
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.
Yeah. Stringency and rigor are words that come to mind.