public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Dewei Dai <[email protected]>
Cc: li.evan.chao <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Pgsql Hackers <[email protected]>
Subject: Re: Serverside SNI support in libpq
Date: Fri, 16 Jan 2026 15:44:55 -0800
Message-ID: <CAOYmi+nsqYiXLxN7G4A5edBJWXZ8qD=zFnaE2bEzuMj2_xBT7Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAOYmi+mSrV8hRaQkvGDf1Df4cmpv5SeTbTxppyxeonMe6MW8nA@mail.gmail.com>
<[email protected]>
<aa7gx3mychf3m2g67mbslzbxjy3if4enpcflstoa5pol3432x5@ugqz45gsvurq>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAOYmi+m2Ks7D4obtXay3y-UNn6CkTNrmr_zWC25vKTdesatafA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAGECzQTWH-bzHcdPo=i09TL_P6_HBBNEkBmr+rpN_J9zVfR2Fw@mail.gmail.com>
<[email protected]>
<CAOYmi+=u=vS1beiog6p5e843uVdout9qZY=pRj4vo=jCVwgGTA@mail.gmail.com>
<[email protected]>
<CAOYmi+mZ=i55iH44zPqidZfoNDLwPBMD=PUtD03LR2ut+zMEag@mail.gmail.com>
<[email protected]>
<CAOYmi+m05X5fRaeV7w3y4VOePnJJQrihK9A_6ma3e5Pesa5mXA@mail.gmail.com>
<[email protected]>
[skipping right to the weird part, will circle back to the other
questions later]
On Tue, Jan 13, 2026 at 1:57 AM Daniel Gustafsson <[email protected]> wrote:
> I think the attached is pretty clear improvement over the previous version so
> thanks for the review suggestions. That being said, the test which was
> reported to still fail upstream is failing here as well (it does the right
> thing with the connection, but terminates the handshake in a different place).
> In an attempt to fix that I moved to using the ClientHello callback which
> OpenSSL document to be the right one (yet they use the servername callback
> themselves), but it renders the same result. I hope that your eagle eyes (or
> someone elses) can figure out either what is wrong, or if this is a different
> form of right. The same failing test is added to 0001 to run it in a strictly
> non-SNI config as well.
I hadn't realized that this also regressed without SNI! That helped a lot.
With 0001, the bug is this diff, which runs the verify_cb regardless
of the ssl_ca setting:
> - SSL_CTX_set_verify(context,
> - (SSL_VERIFY_PEER |
> - SSL_VERIFY_CLIENT_ONCE),
> - verify_cb);
> }
>
> + /*
> + * Always ask for SSL client cert, but don't fail if it's not presented.
> + * We might fail such connections later, depending on what we find in
> + * pg_hba.conf.
> + */
> + SSL_CTX_set_verify(context,
> + (SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE),
> + verify_cb);
0002 undid that but reintroduced it in be_tls_open_server():
> /* enable ALPN */
> SSL_CTX_set_alpn_select_cb(SSL_context, alpn_cb, port);
>
> + SSL_CTX_set_verify(SSL_context,
> + (SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE),
> + verify_cb);
If I remove that diff, the regression goes away. But then we start
failing SNI tests:
> [14:24:05.901](0.000s) not ok 72 - host: 'example.com', ca: 'root+client_ca.crt': connect with sslcert, client certificate sent: no stderr
> [14:24:05.902](0.000s) # Failed test 'host: 'example.com', ca: 'root+client_ca.crt': connect with sslcert, client certificate sent: no stderr'
> # at src/test/ssl/t/004_sni.pl line 314.
> [14:24:05.902](0.000s) # got: 'psql: error: connection to server at "127.0.0.1", port 15428 failed: FATAL: connection requires a valid client certificate'
> # expected: ''
> [14:24:05.917](0.000s) not ok 76 - host: 'example.net', ca: 'root+server_ca.crt': connect with sslcert, client certificate sent: matches
> [14:24:05.917](0.000s) # Failed test 'host: 'example.net', ca: 'root+server_ca.crt': connect with sslcert, client certificate sent: matches'
> # at ssl/t/004_sni.pl line 327.
> [14:24:05.917](0.000s) # 'psql: error: connection to server at "127.0.0.1", port 15428 failed: FATAL: connection requires a valid client certificate'
> # doesn't match '(?^:unknown ca)'
I think the root problem probably comes back to SSL_set_SSL_CTX [1].
That copies the certificate over from the new SSL_CTX, but it doesn't
really seem to care about much else, and there are a _lot_ of settings
copied into the SSL pointer during initial connection [2] that are
ignored there.
The verify mode and callback are two such settings. So is the password
callback (which may mean that the new per-host-line logic for
openssl_tls_init_hook won't work correctly either).
So unless Matt Caswell knows of an existing API that does this right,
I think I'm coming back to the idea that we should keep a single
SSL_CTX, and then use the selected HostsLine to override individual
connection settings during the clienthello/servername callback. Do we
give anything up with that approach?
--Jacob
[1] https://postgr.es/m/CAOYmi%2Bk%3DVF-2BCqfR49A92tx%3D_QNuL%3D3iT3w6FysOffKw9cxDQ%40mail.gmail.com
[2] https://github.com/openssl/openssl/blob/5d401004a0/ssl/ssl_lib.c#L731
view thread (58+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Serverside SNI support in libpq
In-Reply-To: <CAOYmi+nsqYiXLxN7G4A5edBJWXZ8qD=zFnaE2bEzuMj2_xBT7Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox