Hacker News new | ask | show | jobs
by j16sdiz 974 days ago
I guess the parent post want to know if there are any _specific_ and _effective_ change for this kind of attacks.

In this case, simplifying the protocol won't help -- the vulnerability is:

  1. Backend servers can't cancel immediately (this is no protocol problem)

  2. The client can make concurrent request in a connection (This is the goal of Http/2)

  3. The concurrency is pre determined, there is no way for the server to throttle without user-visible error.
 
  4. The client can cancel any request mid-flight (removing this is equally bad, security-wise)
Unless you are removing the concurrency, making the protocol simpler won't fix it.

The protocol designer need adversary mindset, not a simpler mind
2 comments
tedunangst 974 days ago
You should be able to cancel a request, but you don't get it back (as in, can't send another) until the server acks the cancel.
link
kuekacang 974 days ago
In agent-like app sure. But how would you detect connections from multiple client instance?
link
crote 974 days ago
If I understand it correctly, a big part of the problem is that 1) requests which are in the process of being cancelled are not counted towards the concurrency limit, and 2) you can create and cancel a request in the same package.

1 allows you to have more pending requests than intended, making some form of DDoS possible. 2 allows it to trivially scale to hundreds of requests per packet rather than just the pending-stream limit, limited only by the packet size.

Disallowing 2 should be fairly trivial, as there is no valid reason to cancel a request in the same packet you started it. I'd consider it more of an implementation bug than a protocol problem.

Issue 1 is definitely a protocol problem though, and it's going to be a bit trickier to fix as it would require nontrivial changes to the request state machine. A fix would require subtracting a request from the pending-stream count not when it is cancelled, but when its resources have been fully cleaned up - and ideally you'd even add some sort of throttling on that to make it even harder to abuse.

link