Slow read attack in HTTP/2

[Valentin V. Bartenev]

On Monday 22 August 2016 12:40:46 Sharan J wrote:
> Hi,
> 
> The scenario which I mentioned was only tested and reported by imperva and
> Nginx has said that they have solved this slow read issue.
> References:
> http://www.imperva.com/docs/Imperva_HII_HTTP2.pdf
> https://www.nginx.com/blog/the-imperva-http2-vulnerability-report-and-nginx/
> 
[..]

They spotted a connection leak, that was already known as ticket #626:
https://trac.nginx.org/nginx/ticket/626 and it was solved in 1.9.12.

Nothing more.


> But as you say, the problem still persists? We can prevent a single client
> from requesting large amount of resources but what if the attacker uses
> multiple machines to make an attack?

You can configure any limits using limit_req and limit_conn modules:
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
and protect your server even if attacker uses multiple machines.


> Is there any check in nginx to examine the client's initial congestion
> window setting and close the connection if it says initial congestion
> window size to be less than 65,535 bytes (as mentioned in RFC
> <https://tools.ietf.org/html/rfc7540#section-5.2.1> as this to be the
> minimum initial congestion window size).

65,535 bytes is just the default, not the minimum (and in fact, nginx
may use even zero initial window).

Such check is useless, since a client can exhaust any initial window and
then stop sending or receiving.

  wbr, Valentin V. Bartenev