<p dir="ltr"><br /> On Jun 24, 2015 7:40 PM, "Andres Freund" <<a
href="mailto:andres@anarazel.de">andres@anarazel.de</a>>wrote:<br /> ><br /> > On 2015-06-24 12:57:03 -0400,
RobertHaas wrote:<br /> > > On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> > > > Andres Freund <<a
href="mailto:andres@anarazel.de">andres@anarazel.de</a>>writes:<br /> > > >> I, by now, have come to a
differentconclusion. I think it's time to<br /> > > >> entirely drop the renegotiation support.<br /> >
>><br /> > > > Well, that's a radical proposal, but I think we should take it seriously.<br /> > >
><br/> > > > On balance I think I agree that SSL renegotiation has not been worth the<br /> > > >
trouble. And we definitely aren't testing it adequately, so if we wanted<br /> > > > to keep it then there's
even*more* work that somebody ought to expend.<br /> > ><br /> > > I'd like to know what factors we are
balancingagainst each other.<br /> ><br /> > Benefits:<br /> ><br /> > SSL renegotiation limits the
exposureof on-the-wire material that's<br /> > leaked if either client or server is hijacked during a existing<br />
>session. With renegotiation the client/server will hopefully only have<br /> > the currently negotiated symetric
key,covering only<br /> > session_renegotiation_limit bytes, in memory.<br /> ><br /> > That's nice, but from
apractical point of view it's not worth all that<br /> > much. If the server has been hacked nearly all the data is
accessible<br/> > anyway, and even if not, the hacker can just continue collecting data<br /> > going forward.
Ifthe client has been hacked, it's likely that it has<br /> > been relegating data for the session to somewhere
that'sstill<br /> > accessible.<br /> ><br /> > For the server hacked case all that generally only matters if
perfect<br/> > forward secrecy (PFS) has been employed, without that the session keys<br /> > can be recovered
anywayas the private key will be accessible in memory.<br /> ><br /> > All this only matters for hacks that
accessrunning processes.<br /> ><br /> > Deficits:<br /> ><br /> > SSL renegotiation has had several
weaknesses(c.f. CVE-2009-3555/RFC<br /> > 5746 , although I'm not 100% sure it's possible to apply to PG) on the<br
/>> protocol level, at least partially leading to much worse vulnerabilities<br /> > than renegotiation in the pg
stylefixes. The openssl implementation has<br /> > had several bugs several of them unfixed years after they were
reported<br/> > (#3712, #2481, #2146,...). By my reading of openssl's code the current<br /> > state is entirely
brokenfor duplex communication.<br /> ><br /> > The current draft of the next version of the TLS standard
removes<br/> > renegotiation entirely.<br /><p dir="ltr">I think this is a very strong argument against it. If the
standardspeople now think it's a bad idea, we shouldn't encourage it. <p dir="ltr">That's assuming they haven't
replacedit with something else (even more complicated of course), and not just removed it. But i don't think they did.
<pdir="ltr">/Magnus
