Slow read attack in HTTP/2

Valentin V. Bartenev vbart at
Mon Aug 22 10:12:08 UTC 2016

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:

They spotted a connection leak, that was already known as 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:
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
> <> 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 mailing list