Re: PostgreSQL not setting OpenSSL session id context?

>
> Shay Rojansky <roji(at)roji(dot)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).
>

I think there may be a confusion here - I'm not doing anything with session
IDs, merely setting the session ID *context*. This seems to be an
OpenSSL-specific feature (nothing to do with TLS) that simply allows
distinguishing between different "applications" (or contexts) running in
the same process. See
https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_session_id_context(3)
for the docs.

This feature does not involve writing anything (and definitely not session
IDs) to stable storage. The idea is to provide the client with an opaque
"session ticket", which is passed by the client back to the server on
subsequent connections, and which allows the skipping of a roundtrip in the
SSL handshake.

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

Again, there's no backend cache - RFC5077 is about having all state at the
client side.

> 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.
>

I may definitely be wrong about this, but I'm under the impression that
management of the session ticket (as of the entire resumption mechanism) is
OpenSSL's responsibility and does not require anything from PostgreSQL
itself. However, if you're suspicious of OpenSSL itself that's another
story (and I'd definitely understand).

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

I will be able to test this later tonight and confirm. I'm not sure why
the SSL_OP_NO_TICKET is in an #ifdef, I would simply do it in all cases.
I've seen people reporting that this issue is solved via setting
SSL_OP_NO_TICKET (e.g.
https://forums.aws.amazon.com/message.jspa?messageID=505895) so I'm not
sure what SSL_CTX_set_session_cache_mode is supposed to add, but if the
idea is to defensively disable other forms of caching than it makes sense.

Just to be clear, I don't necessarily have a problem with disabling RFC5077
session resumption as the benefits in the PostgreSQL scenario aren't big
(although I don't think a handshake roundtrip is completely negligible
either). I just think it's advisable we understand exactly what it is we're
disabling - there seems to be a confusion between session IDs, session ID
contexts, server/client-side state etc.