Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\))
Subject: Re: Serverside SNI support in libpq
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <afb479af-2fe7-4790-ad11-437a326329b5@iki.fi>
Date: Wed, 3 Dec 2025 17:52:09 +0100
Cc: Dewei Dai <daidewei1970@163.com>,
 "li.evan.chao" <li.evan.chao@gmail.com>,
 Jacob Champion <jacob.champion@enterprisedb.com>,
 Michael Paquier <michael@paquier.xyz>,
 Andres Freund <andres@anarazel.de>,
 Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B@yesql.se>
References: <88986722-5A72-4DEC-8750-BDBF67FF8C01@yesql.se>
 <CAOYmi+nYV6Rr9BY4YfYyVdiQ5TzMZray6QPXwiO3pYSaow+-Tg@mail.gmail.com>
 <7E77028B-5A3A-436B-9046-8E9992E9F94A@yesql.se>
 <Z1jeINLtB05YMVOY@paquier.xyz>
 <E51258CD-C7B2-4BB1-AB9C-A3DD2B6592D0@yesql.se>
 <F4222274-15C0-40E4-84FB-8FC1355BB8B2@yesql.se>
 <CAOYmi+mSrV8hRaQkvGDf1Df4cmpv5SeTbTxppyxeonMe6MW8nA@mail.gmail.com>
 <0BC5B9B1-6503-4563-AAC6-33DEF264AE3F@yesql.se>
 <aa7gx3mychf3m2g67mbslzbxjy3if4enpcflstoa5pol3432x5@ugqz45gsvurq>
 <F585452A-1F69-4658-A7E8-D1273AC663ED@yesql.se>
 <aLT9xVsTVp0j3zWy@paquier.xyz>
 <80F4F8F4-8E4F-4B6F-866B-D837057C1192@yesql.se>
 <D9F6F14D-FCB1-48B5-9CBC-AE89FA0AEF4C@yesql.se>
 <CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
 <0C53C316-C24E-4307-807B-D825CA3F7254@yesql.se>
 <DD77A37A-BFCA-4819-A029-1A41E2443D8E@gmail.com>
 <378D83FA-338C-4EA1-BC60-397BE08D0F01@yesql.se>
 <2025112617144938459246@163.com>
 <0217DEFA-9684-4A77-A005-D30EBEF155C4@yesql.se>
 <afb479af-2fe7-4790-ad11-437a326329b5@iki.fi>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Archived-At: 
 <https://www.postgresql.org/message-id/5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B%40yesql.se>
Precedence: bulk

> On 3 Dec 2025, at 10:57, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>=20
> Sorry for jumping in so late.

Not at all, thanks for looking!

> 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.=20

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.

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

I have that on my if-it-gets-committed TODO but I kept it out of the =
initial
proposal to keep complexity down and goalposts in sight.

> 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=3Don =
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?

--
Daniel Gustafsson