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.
HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
41–50 of 82 posts
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#42This 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.
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#43This seems like a hyperbolic misuse of both “vulnerability” and “zero-day”.
How is it not a vulnerability?
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#44Earlier 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 eight years for somebody to use this. We don't know when it was discovered (nor how many times by how many different people.)
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#45This 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.
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#46This seems like a hyperbolic misuse of both “vulnerability” and “zero-day”.
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.
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#47So 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?
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#48Earlier quoted context omitted.
It took 8 years for somebody to discover this. It can't have been that obvious.
It took eight years for somebody to use this. We don't know when it was discovered (nor how many times by how many different people.)
I remember noticing this from the HTTP/2 RFC, maybe 8y ago. I was studying the head of line blocking issue on a custom protocol atop TCP and was curious to compare with HTTP/2. I think I might even have chatted with a coworker about it at the time, as he was implementing grpc (which uses HTTP/2) in Rust.
It never occured to me that it could be used nefariously!
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#49So 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.)
Re: HTTP/2 zero-day vulnerability results in record-breaking DDoS attacks
#50Earlier quoted context omitted.
Not everyone cares about Cloudflare, or even HTTP/2. The exploit has more to do with their implementation than the protocol.
> 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.