3 ms·
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 sho
by insanitybit 3y ago
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.
- throw0101c 3y ago> assuming that this is "complexity bloat" and not just "a feature that people use" ¿Por qué no los dos? :)
- insanitybit 3y agoWell, to me "bloat" and "useful + used" are incompatible. The feature only made it into HTTP/2 because it saw validation from gRPC, I believe.
- sophacles 3y agoBloat implies that it isn't useful - that it's just dead weight. If a lot of people use the thing, it must provide some value to them.
- neild 3y agoHTTP/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 stream limit after a stream closes, so there is backpressure limiting how quickly the sender may create streams.
- insanitybit 3y agoThanks. I'm curious to see how the backpressure ends up playing out in terms of "do you need 10k boxes to DoS vs 100k vs not feasible".