Re: Serverside SNI support in libpq
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Cary Huang <cary.huang@highgo.ca>
Cc: pgsql-hackers@lists.postgresql.org, Daniel Gustafsson <daniel@yesql.se>
Date: 2024-07-25T18:00:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ssl: Serverside SNI support for libpq
- 4f433025f666 19 (unreleased) landed
-
ssl: Add tests for client CA
- 25e568ba7ce7 19 (unreleased) landed
On Fri, May 24, 2024 at 12:55 PM Cary Huang <cary.huang@highgo.ca> wrote: > pg_hosts should also have sslpassword_command just like in the postgresql.conf in > case the sslkey for a particular host is encrypted with a different password. Good point. There is also the HBA-related handling of client certificate settings (such as pg_ident)... I really dislike that these things are governed by various different files, but I also feel like I'm opening up a huge can of worms by requesting nestable configurations. > + if (ssl_snimode != SSL_SNIMODE_OFF) > + SSL_CTX_set_tlsext_servername_callback(context, sni_servername_cb); > > If libpq client does not provide SNI, this callback will not be called, so there > is not a chance to check for a hostname match from pg_hosts, swap the TLS CONTEXT, > or possibly reject the connection even in strict mode. I'm mistrustful of my own test setup (see previous email to the thread), but I don't seem to be able to reproduce this. With sslsni=0 set, strict mode correctly shuts down the connection for me. Can you share your setup? (The behavior you describe might be a useful setting in practice, to let DBAs roll out strict protection for new clients gracefully without immediately blocking older ones.) Thanks, --Jacob