Re: PostgreSQL not setting OpenSSL session id context?

Shay Rojansky <roji@roji.org>

From: Shay Rojansky <roji@roji.org>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@postgresql.org
Date: 2017-08-04T18:48:20Z
Lists: pgsql-hackers
>
> On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote:
> > I'm still not convinced of the risk/problem of simply setting the session
> > id context as I explained above (rather than disabling the optimization),
> > but of course either solution resolves my problem.
>
> How would that do anything? Each backend has it's own local
> memory. I.e. any cache state that openssl would maintain wouldn't be
> useful. If you want to take advantage of features around this you really
> need to cache tickets in shared memory...
>

Guys, there's no data being cached at the backend - RFC5077 is about
packaging information into a client-side opaque session ticket that allows
skipping a roundtrip on the next connection. As I said, simply setting the
session id context (*not* the session id or anything else) makes this
feature work, even though a completely new backend process is launched.

Commits

  1. Disallow SSL session tickets.