61–70 of 82 posts
So is nginx with http2 enabled vulnerable too? Caddy? I should I not worry about this, because a small (by Cloudflare scale) botnet may DDoS a single server completely anyway?
Go is patching it soon: https://github.com/caddyserver/caddy/issues/5877#issuecommen... (Caddy just uses Go's HTTP/2 implementation.)
Earlier quoted context omitted.
> The exploit has more to do with their implementation than the protocol. Is it? I imagine that implementations can do things like make creating/dropping a stream faster but how would an implementation flat out mitigate this?
There is a maximum bandwidth at which data can arrive. Simply make sure you can always process it faster than the next packet can arrive, or implement proper mitigation in cases where you cannot. It's called programming under soft real-time constraints.
The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
The largest DDoS attack to date, peaking above 398M rps - https://news.ycombinator.com/item?id=37831062
This seems like a hyperbolic misuse of both “vulnerability” and “zero-day”.
How is it not a vulnerability?
Earlier quoted context omitted.
Bit of a leading question since you assuming that this is "complexity bloat" and not just "a feature that people use", but yes, HTTP/3 has streams and so it should be vulnerable.
HTTP/3 is not vulnerable to this specific attack (Rapid Reset), because there it has an extra confirmation step before the sender can create a new stream. HTTP/2 and HTTP/3 both have a limit on the number of simultaneous streams (requests) the sender may create. In HTTP/2, the sender may create a new stream immediately after sending a reset for an existing one. In HTTP/3, the receiver is responsible for extending the…
>HTTP/2 protocol — a fundamental protocol that is critical to how the Internet and all websites work No, it isn't. This whole article seems more like a marketing sales pitch than a disclosure.
I visited a few common sites and they seem to use HTTP/2. I'm not sure the point of arguing it's not fundamental, a cursory glance shows HTTP/1 is bottlenecked by not being able to use the same TCP connection to serve multiple resources (something HTTP/2 fixes)? Is there ire against HTTP/2 adoption, and for what reasons?
Earlier quoted context omitted.
There is a maximum bandwidth at which data can arrive. Simply make sure you can always process it faster than the next packet can arrive, or implement proper mitigation in cases where you cannot. It's called programming under soft real-time constraints.
Well yeah, that's just how DoS kinda works with these sorts of vulns. "Be faster" is obviously a good strategy, but is it viable ? Is setting up and canceling a stream something that can be done at GB/s speeds? Maybe, idk.
In the real world, pipes cannot put arbitrary pressure, so your constraint is more bounded than this. So if you receive 2000 psi but your pipes can only handle 1000, you just need a small component that can handle the 2000 to split the pressure in two, and you can handle it all without releasing any.
The same applies to digital logic; it's always possible to build something such that you can guarantee processing within a bounded amount of time by optimizing and sizing the resources correctly.
As the word "digital logic" suggests, these sorts of guarantees are more often applied when designing hardware than software, but they can apply to either.
Earlier quoted context omitted.
How is it not a vulnerability?
What is the vulnerability anyway? I skimmed the linked article twice and could find no explanation of how it works, beyond "request, cancel, request, cancel" and that it's called Rapid Reset. Why is HTTP/2 in particular vulnerable? Are all protocols supporting streams vulnerable? How is it possible to vomit such a long article with so little information?
Earlier quoted context omitted.
> The exploit has more to do with their implementation than the protocol. Is it? I imagine that implementations can do things like make creating/dropping a stream faster but how would an implementation flat out mitigate this?
There is a maximum bandwidth at which data can arrive. Simply make sure you can always process it faster than the next packet can arrive, or implement proper mitigation in cases where you cannot. It's called programming under soft real-time constraints.