Re: PostgreSQL not setting OpenSSL session id context?

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 <tgl(at)sss(dot)pgh(dot)pa(dot)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
>