Hello!

On Fri, Dec 09, 2022 at 09:38:47AM +0000, Roman Arutyunyan wrote:

> # HG changeset patch
> # User Roman Arutyunyan <arut@nginx.com>
> # Date 1670322119 0
> # Tue Dec 06 10:21:59 2022 +0000
> # Branch quic
> # Node ID 1038d7300c29eea02b47eac3f205e293b1e55f5b
> # Parent b87a0dbc1150f415def5bc1e1f00d02b33519026
> QUIC: ignore server address while looking up a connection.
>
> The server connection check was copied from the common UDP code in c2f5d79cde64.
> In QUIC it does not make much sense though. Technically client is not allowed
> to migrate to a different server address. However, migrating withing a single
> wildcard listening does not seem to affect anything.

Wildcard address might be used for a catch-all listening socket,
"if there are several listen directives with the same port but
different addresses, and one of the listen directives listens on
all addresses for the given port (*:port)"
(http://nginx.org/r/listen). For example, in a configuration like
the following:

server {
listen 80;
return 404;
}

server {
listen 127.0.0.1:80;
return 200 secret;
}

This will create just one listening socket on *:80, but only
clients connecting to 127.0.0.1:80 will be able to see the secret.

Distinction between such connections in case of http happens in
ngx_http_init_connection(), see "if (port->naddrs > 1)". In
stream and mail, similar ifs are in ngx_stream_init_connection()
and ngx_mail_init_connection().

This distinction is expected to be equivalent to using different
listening sockets as long as socket-specific options are
identical. Distinct sockets can be requested with

listen 127.0.0.1:80 bind;

which is expected to result in exactly equivalent behaviour,
but with distinct listening sockets.

Not sure how this can affect QUIC, but the change essentially
removes distinction between packets sent to different listening
sockets. This might not be a good idea from security point of
view.

As a trivial example, one can block packets to a particular server
address on a firewall (in an attempt to stop an attack), with
something like "block from any to 192.0.2.1", assuming it will
stop traffic to the server in question. Still, with the proposed
change, it will be possible to access resources with a previously
established QUIC connection as long as the attacker knows other IP
addresses used on the same physical server.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel