Re: [PATCH] Accept IP addresses in server certificate SANs

On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> However, 0002,
>
> +/*
> + * In a frontend build, we can't include inet.h, but we still need to have
> + * sensible definitions of these two constants. Note that pg_inet_net_ntop()
> + * assumes that PGSQL_AF_INET is equal to AF_INET.
> + */
> +#define PGSQL_AF_INET (AF_INET + 0)
> +#define PGSQL_AF_INET6 (AF_INET + 1)
> +
>
> Now we have the same definition thrice in frontend code. Coulnd't we
> define them in, say, libpq-fe.h or inet-fe.h (nonexistent) then
> include it from the three files?

I started down the inet-fe.h route, and then realized I didn't know
where that should go. Does it need to be included in (or part of)
port.h? And should it be installed as part of the logic in
src/include/Makefile?

> +$node->connect_fails(
> + "$common_connstr host=192.0.2.2",
> + "host not matching an IPv4 address (Subject Alternative Name 1)",
>
> It is not the real IP address of the server.
>
> https://datatracker.ietf.org/doc/html/rfc6125
> > In some cases, the URI is specified as an IP address rather than a
> > hostname. In this case, the iPAddress subjectAltName must be
> > present in the certificate and must exactly match the IP in the URI.
>
> When IP address is embedded in URI, it won't be translated to another
> IP address. Concretely https://192.0.1.5/hoge cannot reach to the host
> 192.0.1.8. On the other hand, as done in the test, libpq allows that
> when "host=192.0.1.5 hostaddr=192.0.1.8". I can't understand what we
> are doing in that case. Don't we need to match the SAN IP address
> with hostaddr instead of host?

I thought that host, not hostaddr, was the part that corresponded to
the URI. So in a hypothetical future where postgresqls:// exists, the
two URIs

postgresqls://192.0.2.2:5432/db
postgresqls://192.0.2.2:5432/db?hostaddr=127.0.0.1

should both be expecting the same certificate. That seems to match the
libpq documentation as well.

(Specifying a host parameter is also allowed... that seems like it
could cause problems for a hypothetical postgresqls:// scheme, but it's
probably not relevant for this thread.)

--Jacob