public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Daniel Gustafsson <[email protected]>
To: Dewei Dai <[email protected]>
Cc: li.evan.chao <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Subject: Re: Serverside SNI support in libpq
Date: Wed, 3 Dec 2025 11:57:32 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAOYmi+nYV6Rr9BY4YfYyVdiQ5TzMZray6QPXwiO3pYSaow+-Tg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAOYmi+mSrV8hRaQkvGDf1Df4cmpv5SeTbTxppyxeonMe6MW8nA@mail.gmail.com>
	<[email protected]>
	<aa7gx3mychf3m2g67mbslzbxjy3if4enpcflstoa5pol3432x5@ugqz45gsvurq>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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

view thread (58+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Serverside SNI support in libpq
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox