Hacker News Reader

Comment by ada1981 | Hacker News Reader

ada1981

So a single machine can do ~ 20,000 rps?

Depends, but there seems to be a multiplier effect at play with this attack. A single client request may result in 100x the work for the server. More details here: https://cloud.google.com/blog/products/identity-security/how...

> Another advantage the attacker gains is that the explicit cancellation of requests immediately after creation means that a reverse proxy server won't send a response to any of the requests. Canceling the requests before a response is written reduces downlink (server/proxy to attacker) bandwidth.

How is this an advantage? Can someone explain please?

It's an advantage because you as a botnet client have made the server side do extra work. You sent two packets, one to request a new connection, and a second to immediately cancel the request. The server on the other hand sees a connection request and does some work like allocating memory and fetching the resource you requested. Once the server starts sending the response back to the client via the reverse proxy, the reverse proxy notices the request is no longer current and just drops the response on the floor. As a result, you made the server do some amount of work and you don't have to worry about saturating your internet connection. They call this a magnification attack because for the cost of two requests you made the server do some multiple of work.

You could add some smarts to the server or reverse proxy that delays starting work in case a cancellation request quickly arrives. This is probably part of the mitigation work they refer to in the article.

The attacking system is shooting a firehose of requests at the target system, but doesn't have to deal with handling any responses being sent back to the requesting systems.

Makes sense, thank you!

This is sort of an aside based on something I read in the article but does anyone know why the RFC guidelines say that you should first send an informational GOAWAY that does not prevent opening new streams when gracefully closing a connection?

They point out in the article that it's a better practice to immediately limit stream creation when you detect abuse - not wait for a round trip to complete first. I'm sure there's a good reason for the original guidelines; I'm just trying to get it and haven't found anything clarifying through Google. Was it specified before the rise of modern attacks?

How do you act on a GOAWAY you haven't received and allowing the server to unilaterally stop supporting things can lead to weird edge cases.

After all you could say any client ignoring a GOAWAY is either bugged or malicious but certainly not until you get confirmation they go it.

Yep: "a client can send a RST_STREAM frame for a single stream. This instructs the server to stop processing the request and to abort the response, which frees up server resources and avoids wasting bandwidth."

Pretty clever

Of course. Depending on the machine and on the network, a single modern machine can do even up to a few millions RPS. This is routinely used in benchmarking tools.

Here with the "attack", it's simply exploiting the ability of HTTP/2 to compress requests and reduce them to just a few bytes, meaning that within a few kilobytes of data you can easily have hundreds of requests. Again this is not new and was already being discussed in 2012 about SPDY's use of zlib to compress requests.

The extra stuff that seems to have made this attack "new" for such service providers is that attackers took care of closing their requests so as not to have to wait for a response and be able to fill the wire with a flow of request. Again this has been known from the inception of HTTP/2 and routinely met by those dealing with proxies which timeout and send headers followed by rst_stream.

Here it makes noise because new records were broken, and likely because the stacks in place were not properly designed so they omitted to check for the real number of streams and only focused on the protocol validity...

Reply on news.ycombinator.com