Heikki Linnakangas <hlinn...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers