Just to continue the above, I can confirm that adding a simple call to SSL_CTX_set_session_id_context() to be_tls_init() with some arbitrary const value fixes the error for me. Attached is a patch (ideally a test should be done for this, but that's beyond what I can invest at the moment, let me know if it's absolutely necessary).
On Mon, Jul 31, 2017 at 1:15 AM, Shay Rojansky <r...@roji.org> wrote: > Hi Tom. > > Again, I know little about this, but from what I understand PostgreSQL > wouldn't actually need to do/implement anything here - the session ticket > might be used only to abbreviate the SSL handshake (this would explain why > it's on by default without any application support). In other words, simply > setting the session context id may make the problem go away and at the same > time unlock the abbreviated SSL handshake optimization. I could be wrong > about this though. > > Whether the above is correct or not, SSL resumption - which removes a > network roundtrip from the connection process - may be a worthy > optimization even for long-lived connections such as PostgreSQL, although > obviously much less valuable than, say, short-lived HTTP connections. > > But regardless, it seems that as you say: if you *don't* want to support > resumption, you're required to explicitly disable it with > SSL_OP_NO_TICKET. > > Just to give some context, Npgsql has its own, internal TLS implementation > which does not implement session tickets at the client side - this is the > workaround currently used. However, it would be much better if the standard > .NET SSL implementation could be used instead (i.e. I'm hoping a backport > would be possible here). > > On Sun, Jul 30, 2017 at 10:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I wrote: >> > I think what you need to do is tell SslStream not to expect that PG >> > servers will do session resumption. (I'm a bit astonished that that >> > would be its default assumption in the first place, but whatever.) >> >> Actually, after a bit of further googling, it seems that the brain >> damage here may be on the server side. It seems that OpenSSL will >> send a session ticket if requested, even though the surrounding >> application has given it no means to identify the session (!?). >> Apparently we need to pass SSL_OP_NO_TICKET to SSL_CTX_set_options >> to prevent that from happening. >> >> regards, tom lane >> > >
openssl-set-session-id-context.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
