Message-ID: <afb479af-2fe7-4790-ad11-437a326329b5@iki.fi>
Date: Wed, 3 Dec 2025 11:57:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Serverside SNI support in libpq
To: Daniel Gustafsson <daniel@yesql.se>, Dewei Dai <daidewei1970@163.com>
Cc: "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>
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>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <0217DEFA-9684-4A77-A005-D30EBEF155C4@yesql.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/afb479af-2fe7-4790-ad11-437a326329b5%40iki.fi>
Precedence: bulk

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