Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#31

Post by juped »

drewg123 wrote: post #28
dartos wrote: post #17

Does HTTP/3 suffer from this kind of complexity bloat?

Well, it requires almost an order of magnitude more energy to serve HTTP/3 than HTTP/1, so maybe? Why do I say this? Because it breaks nearly every optimization that's been made to serve content efficiently over the last 25 years (sendfile, TSO, kTLS, etc), and requires that the server's CPU touch every byte of data multiple times (rather than never, for http/1). Its basically the "what if I do everything wrong" case…

no it's more efficient in every way, they called it QUIC not SLO

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#32

Post by da_chicken »

bflesch wrote: post #5
formerly_proven wrote: post #2

tl;dr HTTP/2 allows clients to DDoS backends much more effectively by using the multiple-stream feature of HTTP/2 to amplify their attack directly inside the reverse proxy (which typically translates HTTP/2 to HTTP/1). > When Cloudflare's reverse proxies process incoming HTTP/2 client traffic, they copy the data from the connection’s socket into a buffer and process that buffered data in order. As each request is rea…

how on earth did nobody anticipate this kind of attack when designing the protocol? it's very obvious it can be abused like this

From what I can tell, people were talking about reset flooding that was dated back in July. Not as a novel thing, either. It's just one of several known vulnerabilities, suggesting they've known about this kind of thing for awhile.

https://pentestmag.com/good-bad-and-the-ugly-of-http-2/

I genuinely don't know if this is real a zero day, or if it's a known protocol vulnerability that nobody was mitigating.

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#33

Post by otbutz »

anshargal wrote: post #22

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?

nginx: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacti...

caddy: https://github.com/caddyserver/caddy/issues/5877

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#34

Post by jeffbee »

insanitybit wrote: post #8

I'm curious to learn more. How how much work is it to establish a stream and close it? It feels like something that could be done very quickly, but it also involves setting up some state (stream buffers) that could be a problem too.

The cost comes from initiating the request to some backend which presumably starts working on it.

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#36

Post by gruez »

notpachet wrote: post #7
turminal wrote: post #4

A number of people have expressed concerns about making the relatively simple protocol more and more complicated in the name of performance. This looks like it's going to be their "Ha, told you so!" moment.

It reminds me of Meltdown/Spectre: you have a pipe, and instructions need to flow through it in a single file line. Let's increase performance by allowing things to be sent/processed out-of-order!

technically the issue is speculative execution, not superscalar execution (ie. "allowing things to be sent/processed out-of-order!"). Most high performance processors have both, but you can have one without the other.

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#37

Post by giantrobot »

juped wrote: post #31
drewg123 wrote: post #28

Earlier quoted context omitted.

Well, it requires almost an order of magnitude more energy to serve HTTP/3 than HTTP/1, so maybe? Why do I say this? Because it breaks nearly every optimization that's been made to serve content efficiently over the last 25 years (sendfile, TSO, kTLS, etc), and requires that the server's CPU touch every byte of data multiple times (rather than never, for http/1). Its basically the "what if I do everything wrong" case…

no it's more efficient in every way, they called it QUIC not SLO

That's why they don't have data centers in San Luis Obispo.

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#38

Post by [deleted] »

insanitybit wrote: post #19
notpachet wrote: post #7

Earlier quoted context omitted.

It reminds me of Meltdown/Spectre: you have a pipe, and instructions need to flow through it in a single file line. Let's increase performance by allowing things to be sent/processed out-of-order!

That's a good example, because it would be an incredibly bad decision to drop speculative execution since it leads to a massive performance improvement.

[deleted]

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#39

Post by notpachet »

gruez wrote: post #36
notpachet wrote: post #7

Earlier quoted context omitted.

It reminds me of Meltdown/Spectre: you have a pipe, and instructions need to flow through it in a single file line. Let's increase performance by allowing things to be sent/processed out-of-order!

technically the issue is speculative execution, not superscalar execution (ie. "allowing things to be sent/processed out-of-order!"). Most high performance processors have both, but you can have one without the other.

True, fair point.

Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks

#40

Post by neild »

insanitybit wrote: post #18
dartos wrote: post #17

Does HTTP/3 suffer from this kind of complexity bloat?

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 stream limit after a stream closes, so there is backpressure limiting how quickly the sender may create streams.

Post reply on HN