Re: Serverside SNI support in libpq

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Daniel Gustafsson <daniel@yesql.se>, Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Dewei Dai <daidewei1970@163.com>, "li.evan.chao" <li.evan.chao@gmail.com>, Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-17T09:03:07Z
Lists: pgsql-hackers
On 12/12/2025 13:41, Daniel Gustafsson wrote:
>> On Wed, Dec 3, 2025 at 1:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> Maybe.  I'm not a big fan of magic-file-exist configurations
>>
>> Me neither. (I especially don't like the idea of ignoring a
>> certificate+key setting that a user has taken the time to put into a
>> config.)

+1

> I wonder if the way forward is to do both?  Heikki has a good point that when
> working with pg_hosts.conf it should be clear from just that file what the
> final config will be, and in the previous version that wasn't the case since
> the ssl_snimode GUC set operation modes.  At the same time, Jacob has a point
> that overriding configuration just because pg_hosts exists isn't transparent.
> 
> Adding a boolean GUC which turns ph_hosts (and thus SNI) on or off can perhaps
> fix both complaints?  If the GUC is on, pg_hosts - and only pg_hosts - is used
> for configuring secrets.  By using the * fallback and no_sni rule in pg_hosts
> all variations of configs can be achieved.  If the GUC is off, then the regular
> SSL GUCs are used and pg_host is never considered (and thus SNI is not
> possible).
> 
> Such a GUC wouldn't make the patch all that much different from what it is
> right now. What do you think about that middleground proposal?

I like that.

Instead of a boolean GUC, it could perhaps be a path to the pg_hosts 
file. I haven't thought this through but somehow it feels more natural 
to me than a "read this file or not" setting.

- Heikki