Heikki Linnakangas <hlinnaka@iki.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
