On 2015-06-24 12:57:03 -0400, Robert Haas wrote: > On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@anarazel.de> writes: > >> I, by now, have come to a different conclusion. I think it's time to > >> entirely drop the renegotiation support. > > > > Well, that's a radical proposal, but I think we should take it seriously. > > > > On balance I think I agree that SSL renegotiation has not been worth the > > trouble. And we definitely aren't testing it adequately, so if we wanted > > to keep it then there's even *more* work that somebody ought to expend. > > I'd like to know what factors we are balancing against each other.
Benefits: SSL renegotiation limits the exposure of on-the-wire material that's leaked if either client or server is hijacked during a existing session. With renegotiation the client/server will hopefully only have the currently negotiated symetric key, covering only session_renegotiation_limit bytes, in memory. That's nice, but from a practical point of view it's not worth all that much. If the server has been hacked nearly all the data is accessible anyway, and even if not, the hacker can just continue collecting data going forward. If the client has been hacked, it's likely that it has been relegating data for the session to somewhere that's still accessible. For the server hacked case all that generally only matters if perfect forward secrecy (PFS) has been employed, without that the session keys can be recovered anyway as the private key will be accessible in memory. All this only matters for hacks that access running processes. Deficits: SSL renegotiation has had several weaknesses (c.f. CVE-2009-3555/RFC 5746 , although I'm not 100% sure it's possible to apply to PG) on the protocol level, at least partially leading to much worse vulnerabilities than renegotiation in the pg style fixes. The openssl implementation has had several bugs several of them unfixed years after they were reported (#3712, #2481, #2146,...). By my reading of openssl's code the current state is entirely broken for duplex communication. The current draft of the next version of the TLS standard removes renegotiation entirely. Additionally supporting SSL renegotiation requires SSL_write/read callers to always call the SSL_write/read after either function has reported the need for additional reads/writes (note that SSL_read can require writes and the other way round). We don't comply with that rule, especially in the backbranches, because it's really hard to do that. Our code currently uses crude hacks (c.f. comment around SSL_clear_num_renegotiations(), and the loop around SSL_do_handshake() in the back branches) to manage renegotiations. There's pending patches to substantially increase the amount of ugly hacking to cope with us misusing the SSL_read/write protocol. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
