Re: PostgreSQL not setting OpenSSL session id context?

Hi Tom and Heikki.

As Tom says, session caching and session tickets seem to be two separate
things. However, I think you may be reading more into the session ticket
feature than there is - AFAICT there is no expectation or mechanism for
restoring *application* state of any kind - the mechanism is only supposed
to abbreviate the SSL handshake itself, i.e. save a roundtrip in the full
handshake process for agreeing on cypher etc. Here's an article I found
useful about this:
https://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077 (in
addition to the RFC itself, of course).

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. So to summarize: at the moment PostgreSQL
indeed provides a session ticket in the first connection, which is cached
on the client side. On the second connection attempt, the (opaque) session
ticket is included in the first SSL packet sent to the server
(ClientHello), but the lack of a session id context causes OpenSSL to
error. In effect, this seems to be a trivial server-side "misconfiguration".

I do understand the reluctance to deal with any SSL "optimizations", having
experienced some of the headaches created by renegotiations. However,
session tickets do seem like a simple and well-defined optimization that
takes effect at connection only. Also, there is no risk of breaking any
*current* clients, since at the moment session tickets simply aren't
supported (because of the lack of session id context). So this seems to me
like a rather low-risk thing to enable. On the other hand, I also
understand that saving a connection-time handshake roundtrip is somewhat
less relevant to PostgreSQL.

I'm a little busy at the moment but if you'd like I can whip up a trivial
client implementation in .NET that demonstrates the issue.

On Tue, Aug 1, 2017 at 12:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > I agree with Tom that we don't really want abbreviated SSL handshakes,
> > or other similar optimizations, to take place. PostgreSQL connections
> > are quite long-lived, so we have little to gain. But it makes the attack
> > surface larger. There have been vulnerabilities related to SSL
> > renegotiation, resumption, abbreviated handshakes, and all that.
>
> > I think we should actually call SSL_CTX_set_session_cache_mode(ctx,
> > SSL_SESS_CACHE_OFF), to disable session caching altogether. I'm not sure
> > if we still need to call SSL_CTX_set_session_cache_mode() if we do that.
>
> AIUI (and I just learned about this stuff yesterday, so I might be wrong)
> session caching and session tickets are two independent mechanisms for
> SSL session reuse.
>
> I have no objection to explicitly disabling session caching, but I think
> it won't have any real effect, because no backend process could ever have
> any entries in its session cache anyway. Maybe it'd result in a more
> apropos error message, don't know.
>
> But we need to disable session tickets separately from that. What's
> happening right now in Shay's case, I believe, is that the client is
> asking for a session ticket and getting one. The ticket contains enough
> data to re-establish the same SSL context with a successor backend;
> but it does not contain any data that would allow restoration of
> relevant backend state. We could imagine "resuming" the session with
> virgin backend state, but I think that violates the spirit if not the
> letter of RFC 5077. In any case, implementing it with those semantics
> would tie our hands if anyone ever wanted to provide something closer
> to true session restoration.
>
> regards, tom lane
>