[PATCH 1 of 6] QUIC: ignore server address while looking up a connection

[Maxim Dounin]

Hello!

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

> # HG changeset patch
> # User Roman Arutyunyan <arut at 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/