Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Shay Rojansky <roji@roji.org> writes:
> Once again, I manged to make the error go away simply by setting the
> session id context, which seems to be a mandatory server-side step for
> properly support session tickets.

The fact that you made the error go away doesn't make this a good
solution.  In particular, using a simple constant session ID is completely
insecure according to the TLS spec.  RFC 5246, F.1.4, doesn't even care
for the idea of ever writing session IDs to stable storage; although
Apache seems to be content with a session ID that is unique per-server
(it looks like they just use a hash of the server's host name).

More generally, PG as currently configured can't do anything with a
session cache since each new backend would start with an empty cache.

So the question here is whether it's safe or worthwhile to allow use
of session tickets.  I agree with Heikki's opinion that it's unlikely
to provide any meaningful performance gain for database sessions that
are of reasonable length.  I'm also pretty concerned about the possibility
for security problems, eg a client being able to force a server into some
low-security SSL mode.  Both RFC 5077 and the Apache people say that if
you use session tickets you'd better rotate the keys for them regularly,
eg in Apache's changelog we find

     Session ticket creation uses a random key created during web
     server startup and recreated during restarts. No other key
     recreation mechanism is available currently. Therefore using session
     tickets without restarting the web server with an appropriate frequency
     (e.g. daily) compromises perfect forward secrecy. [Rainer Jung]

Since we have no mechanism for that, I think that we need to err on
the side of security.

Accordingly, what I think we should do is something more like the
attached.  Could you see whether it fixes your problem?