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 >
