Slow read attack in HTTP/2
Valentin V. Bartenev
vbart at nginx.com
Mon Aug 22 10:12:08 UTC 2016
On Monday 22 August 2016 12:40:46 Sharan J wrote:
> The scenario which I mentioned was only tested and reported by imperva and
> Nginx has said that they have solved this slow read issue.
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.
> 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:
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
More information about the nginx