Re: Serverside SNI support in libpq
| От | Daniel Gustafsson |
|---|---|
| Тема | Re: Serverside SNI support in libpq |
| Дата | |
| Msg-id | 5D0E78E0-EA79-480E-ABD3-B1EF0156BF8B@yesql.se обсуждение исходный текст |
| Ответ на | Re: Serverside SNI support in libpq (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: Serverside SNI support in libpq
|
| Список | pgsql-hackers |
> On 3 Dec 2025, at 10:57, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > 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. 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 canalso specify a "no sni" line which matches connections with no SNI specified. (Or something along those lines, I didn'tthink 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 youhad 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? -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: