News for hackers. Stuff that matters.

A comment on The novel HTTP/2 'Rapid Reset' DDoS attack. Parent comment

Re:The novel HTTP/2 'Rapid Reset' DDoS attack by tptacek on Tuesday October 10, 2023 @10:43AM (#37832750)
I think for this audience a good clarification is:

* HTTP/1.1: 1 request per RTT per connection

* HTTP/2 multiplexing: 100 requests per RTT per connection

* HTTP/2 rapid reset: indefinite requests per connection

In each case attackers are grinding down a performance limitation they had with previous generations of the attack over HTTP. It is a request flood; the thing people need to keep in mind is that HTTP made these floods annoying to generate.

[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by jsnell on Tuesday October 10, 2023 @10:57AM (#37832924)
Indeed, that's a crucial clarification. Thanks.
[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by maxfurman on Tuesday October 10, 2023 @11:55AM (#37833785)
What does RTT stand for? My gut says "Round Trip (something)" but I could certainly be wrong.
[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by hathawsh on Tuesday October 10, 2023 @12:15PM (#37834081)
The HTTP spec defines it as Round Trip Time, but in this little discussion thread, "round-trip transaction" would be a better fit.

https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip...

[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by altairprime on Tuesday October 10, 2023 @01:16PM (#37834773)
In the style of the above clarification, how would you describe HTTP/3 in "x requests (per y)? per connection"?
[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by blauditore on Tuesday October 10, 2023 @03:22PM (#37836292)
What happens if you send more? Does it just get ignored by the server?
[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by jsnell on Tuesday October 10, 2023 @03:27PM (#37836371)
For most current HTTP/2 implementations it'll just be ignored, and that is a problem. We've seen versions of the attack doing just that, as covered in the variants section of the article.

Servers should switch to closing the connection if clients exceed the stream limit too often, not just ignoring the bogus streams.

[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by ynik on Tuesday October 10, 2023 @08:47PM (#37839670)
I wonder why exactly this attack can't be pulled off with HTTP/1.1 and TCP RST for cancellation. It seems that (even with SYN cookies involved) an attacker could create new connections, send HTTP request, then quickly after send a RST.

Is it just that the kernel doesn't really communicate TCP RST all that well to the application, so the HTTP server continues to count the connection against the "open connection limit" even though it isn't open anymore?

[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by wbl on Tuesday October 10, 2023 @09:39PM (#37839983)
The problem for the attacker is they then run into resource limits on the TCP connections. The resets are essential to get the consumption not counting.
[ Parent | on HN ]
Re:The novel HTTP/2 'Rapid Reset' DDoS attack by immibis on Tuesday October 10, 2023 @10:34PM (#37840265)
The server kernel won't communicate the new connection to the application until you go through SYN-SYNACK-ACK.
[ Parent | on HN ]