Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

On Jun 24, 2015 7:40 PM, "Andres Freund" <andres(at)anarazel(dot)de> wrote:
>
> On 2015-06-24 12:57:03 -0400, Robert Haas wrote:
> > On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Andres Freund <andres(at)anarazel(dot)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