public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: 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 18:56:59 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[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]>
	<[email protected]>
	<[email protected]>

On 03/12/2025 18:52, Daniel Gustafsson wrote:
>> On 3 Dec 2025, at 10:57, Heikki Linnakangas <[email protected]> wrote:
>> 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 added the GUC for two reasons; as a way to opt-out of this feature if it's
> something that the admin doesn't want; and as a way to set the SNI mode.  There
> are currently the two modes of STRICT and DEFAULT which affects how incoming
> connections are handled.  The first motivation might be unfounded, and the
> second one could be encoded in a pg_hosts configuration though implicitly
> rather than explicitly.
> 
> Having all the details in pg_hosts.conf is appealing, no disagreement there,
> but it does pose some challenges in the interaction with the postgresql.conf
> GUCS (more later).
> 
>> 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).
> 
> So basically reserving a hostname,"no_sni" or something, which indicates that
> it's for non sslsni connections?  That should work, with the parsing rule that
> there can only be one in the file.

Yeah, something like that. And to implement the "strict" mode, you could 
have a "no_sni" line with no cert/key specified.

>> 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.
> 
> That's a bit trickier though, since the cert/key have a default boot_val so
> they will always be set to something unless the user enables ssl=on and at the
> same time uncomments ssl_cert_file/ssl_key_file and set them to '' before
> proceeding to add configuration in pg_hosts.conf.  This is pretty unintuitive I
> think.  unintuitive.  This backwards comatibility is one of the reasons I kept
> the postgresl.conf values for the default context config.
> 
> I really want to make it possible for anyone who don't want SNI to keep using
> postgresql.conf and get the exact behavior they've always had.  Do you agree
> with that design goal?

Yeah, that's fair.

- 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