good to know, thanks for the info Maxim.

El mar, 10 oct 2023 a las 17:55, Maxim Dounin (<mdounin@mdounin.ru>) escribió:
>
> Hello!
>
> On Tue, Oct 10, 2023 at 05:30:52PM -0400, Rick Gutierrez wrote:
>
> > In the open version 1.24 and 1.25 the correction will be applied?, ¿or in
> > the new release?
>
> To re-iterate:
>
> We do not consider nginx to be affected by this issue. In the
> default configuration, nginx is sufficiently protected by the
> limit of allowed requests per connection (see
> http://nginx.org/r/keepalive_requests for details), so an attacker
> will be required to reconnect very often, making the attack
> obvious and easy to stop at the network level. And it is not
> possible to circumvent the max concurrent streams limit in nginx,
> as nginx only allows additional streams when previous streams are
> completely closed.
>
> Further, additional protection can be implemented in nginx by
> using the "limit_req" directive, which limits the rate of requests
> and rejects excessive requests.
>
> Overall, with the handling as implemented in nginx, impact of
> streams being reset does no seem to be significantly different
> from impacts from over workloads with large number of requests
> being sent by the client, such as handling of multiple HTTP/2
> requests or HTTP/1.x pipelined requests.
>
> Nevertheless, we've decided to implemented some additional
> mitigations which will help nginx to detect such attacks and drop
> connections with misbehaving clients faster. The patch to do so
> was committed (http://hg.nginx.org/nginx/rev/cdda286c0f1b) and
> will be available in the next nginx release.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx



--
rickygm

http://gnuforever.homelinux.com
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx