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 _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
