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

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.

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