On Jun 24, 2015 7:40 PM, "Andres Freund" <and...@anarazel.de> wrote: > > 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.
I think this is a very strong argument against it. If the standards people now think it's a bad idea, we shouldn't encourage it. That's assuming they haven't replaced it with something else (even more complicated of course), and not just removed it. But i don't think they did. /Magnus