Re: Serverside SNI support in libpq

Sorry for jumping in so late.

On Fri, May 10, 2024 at 7:23 AM Daniel Gustafsson
<daniel(at)yesql(dot)se> wrote:
> The attached patch adds serverside SNI support to libpq, it is still a bit
> rough around the edges but I'm sharing it early to make sure I'm not designing
> it in a direction that the community doesn't like. A new config file
> $datadir/pg_hosts.conf is used for configuring which certicate and key should
> be used for which hostname. The file is parsed in the same way as pg_ident
> et.al so it allows for the usual include type statements we support. A new
> GUC, ssl_snimode, is added which controls how the hostname TLS extension is
> handled. The possible values are off, default and strict:
>
>
> - off: pg_hosts.conf is not parsed and the hostname TLS extension is
> not inspected at all. The normal SSL GUCs for certificates and keys
> are used.
> - default: pg_hosts.conf is loaded as well as the normal GUCs. If no
> match for the TLS extension hostname is found in pg_hosts the cert
> and key from the postgresql.conf GUCs is used as the default (used
> as a wildcard host).
> - strict: only pg_hosts.conf is loaded and the TLS extension hostname
> MUST be passed and MUST have a match in the configuration, else the
> connection is refused.
>
>
> As of now the patch use default as the initial value for the GUC

Do we need the GUC? It feels a little confusing that a GUC affects how
the settings in the pg_hosts.conf are interepreted. It'd be nice if you
could open pg_hosts.conf in an editor, and see at one glance everything
that affects this.

I propose that there is no GUC. In 'pg_hosts.conf', you can specify a
wildcard '*' host that matches anything. You can also specify a "no sni"
line which matches connections with no SNI specified. (Or something
along those lines, I didn't think too hard about all the interactions).

Should we support wildcards like "*.example.com* too?

For backwards-compatibility, if you specify a certificate and key in
postgresql.conf, they are treated the same as if you had a "*" line in
pg_hosts.conf.

- Heikki