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

71–80 of 82 posts

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

#71

Post by fanf2 »

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

At least haproxy anticipated it https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...

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

#72

Post by yencabulator »

fzzzy wrote: post #54
mrmuagi wrote: post #52

Earlier quoted context omitted.

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?

http 1.1 connections can be reused, including with pipelining, and it can open multiple sockets to make requests in parallel. http 2 allows out of order responses on one socket. is it worth the complexity? http 1.1 is over 20 years old and battle tested.

Clients stopped using HTTP/1.1 pipelining because it just didn't work well enough.

https://en.wikipedia.org/wiki/HTTP_pipelining#Implementation...

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

#73

Post by _8j50 »

nonane wrote: post #42
_8j50 wrote: post #41

This sounds like an IP spoofing issue, it is an IP/layer3 problem where ISPs don't filter spoofed addresses from their users. There sre technical solutions but should also happen is cutting off these ISPs from the internet as a whole when there is a large scale ddos affecting global scale network performance.

No. This is not a ISP problem and the ISP can not solve this - it’s not even visible to the ISP for encrypted connections. This a problem with HTTP/2 itself that web servers / load balancers / proxies need to account for.

You're right. My fault.

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

#74

Post by _8j50 »

charcircuit wrote: post #45
_8j50 wrote: post #41

This sounds like an IP spoofing issue, it is an IP/layer3 problem where ISPs don't filter spoofed addresses from their users. There sre technical solutions but should also happen is cutting off these ISPs from the internet as a whole when there is a large scale ddos affecting global scale network performance.

This attack just spams requests to a web server. The novel part of the attack is that it also spams packets to cancel those requests to bypass any concurrency limits that may be in place.

Yup, I failed by not actually reading past the first few sentences.

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

#75

Post by immibis »

mgaunard wrote: post #50
insanitybit wrote: post #21

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.

> Simply make sure you can always process it faster than the next packet can arrive

This is pretty much impossible unless you make the client do a proof-of-work so they can't send requests very quickly. Okay, you could use a slow connection so that requests can't arrive very quickly, but then the DoS is upstream.

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

#76

Post by bobby_the_whale »

joshuamorton wrote: post #60
sophacles wrote: post #59

Earlier quoted context omitted.

So your contention is that the creators of HTTP/2 intended for all users of it to be DDoSed?

I mean yes, much as http1 allows for people to be ddosed.

[dead]

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

#77

Post by baobabKoodaa »

jeffbee wrote: post #46
sophacles wrote: post #43

Earlier quoted context omitted.

How is it not a vulnerability?

A vulnerability is a flaw in the implementation that allows an attacked to trigger some kind of unexpected result. The result in this case is defined in an RFC. It is 100% working as intended.

A protocol can also have a vulnerability (the term is not constrained to implementation flaws only)

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

#78

Post by wtarreau »

jsnell wrote: post #9
bflesch wrote: post #5

Earlier quoted context omitted.

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

It took 8 years for somebody to discover this. It can't have been that obvious.

> It took 8 years for somebody to discover this. It can't have been that obvious.

Actually that's not true, it was already suggested here as a way to circumvent the max_concurrent_streams setting an it seemed particularly obvious: https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar...

As soon as you start to implement a proxy that supports H2 on both sides, that's something you immediately spot, because setting too low timeouts on your first stage easily fills the second stage so you have to cover that case.

I think that the reality is in fact that some big corp had several outages due to these attacks and it makes them look better to their customers to say "it's not our fault we had to fight zero-days" than "your service was running on half-baked stacks", so let's just go make a lot of noise about it to announce yet-another-end-of-the-net.

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

#79

Post by wtarreau »

dur-randir wrote: post #51

>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.

Actually even the diagrams are wrong because they focus on a single connection to explain the problem, carefully omitting the fact that a client can easily open many connections to do the same again. I agree it's mostly marketing and press-releases.

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

#80

Post by jsnell »

wtarreau wrote: post #79
dur-randir wrote: post #51

>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.

Actually even the diagrams are wrong because they focus on a single connection to explain the problem, carefully omitting the fact that a client can easily open many connections to do the same again. I agree it's mostly marketing and press-releases.

Yes, the attackers will obviously open many connections. In fact, they've always opened as many connections as they have resources for.

But establishing a connection is extremely expensive compared to sending data on an already established channel. With this method they need to open far fewer connections for the same qps.

There's no need to confuse the issue by trying to diagram multiple connections at the same time.

Post reply on HN