Re: SSL renegotiation

On 2015-02-23 15:15:31 +0100, Florian Weimer wrote:
> On 02/22/2015 02:05 PM, Andres Freund wrote:
> > On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
> >> I honestly wonder why postgres uses renegotiation at all. The motivation
> >> that cryptoanalysis is easier as more data is sent seems quite
> >> far-fetched.
> >
> > I don't think so. There's a fair number of algorithms that can/could be
> > much easier be attached with lots of data available. Especially if you
> > can guess/know/control some of the data. Additionally renegotiating
> > regularly helps to constrain a possible key leagage to a certain amount
> > of time. With backend connections often being alive for weeks at a time
> > that's not a bad thing.
>
> Renegotiation will be removed from future TLS versions because it is
> considered unnecessary with modern ciphers:
>
> <https://github.com/tlswg/tls13-spec/issues/38>
>
> If ciphers require rekeying, that mechanism will be provided at the TLS
> layer in the future.
>
> I think you could remove renegotiation from PostgreSQL as long as you
> offer something better than RC4 in the TLS handshake.

As far as I understand it, this argument misses an important
point. Without protocol level rekeying, handled by the library in the
background, never changing the session key pretty much breaks PFS. In
http the sessions almost always are short enough that such a
consideration doesn't play a role, but it's far from uncommon to have
database connections that live weeks and transport hundreds of gigabytes
in their lifetime.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services