Thread: SSL renegotiation
Hi.
First, SSL_num_renegotiations(port->ssl) always seems to return 1 after calling SSL_renegotiate, so that check below will never throw an error. So clients could now simply ignore Hello Requests and no one would complain.
I noticed your latest mail thread about ssl renegotiations and this commit by hlinnaka: https://github.com/postgres/postgres/commit/272923a0a6956187471df4f032eee06559520390 and how renegotiation is done since that.
Before this commit, after sending a Hello Request, the backend waits until the handshake was completed (it blocks while waiting for a Client Hello).
After this commit, the backend continues to send application data and in the next SSL_read, the handshake messages from the client are processed.
However, there is a problem here: https://github.com/postgres/postgres/blob/1c2b7c0879d83ff79e4adf2c0a883df92b713da4/src/backend/libpq/be-secure-openssl.c#L655
Second, the way of checking the limit that way (if it worked) in be_tls_write is kind of strange, since if writing much data (more than 1 kb) before doing a SSL_read, the client's handshake message (Client Hello) is never processed, so then the handshake will never be able to complete before the renegotiation limit is hit and a fatal error would be thrown. It would somehow be better to wait if the client sends more than allowed without responding to the Hello Request. But clients have the same problem, they might write a lot of data without repeatingly polling the socket if there are Hello Requests available.
One benefit now is however that the server doesn't have to wait the roundtrip after sending a Hello Request until it receives the Client Hello, but instead can send application data interleaved while waiting. However, OpenSSL is broken (as you've already noticed) since it itself does not accept interleaved application data with handshake messages (application data received after Client Hello are considered unexpected messages), so the benefit can currently not be used by the client. See the recently posted http://www.mail-archive.com/openssl-dev@openssl.org/msg38217.html. Also, Microsoft's SslStream doesn't work with renegotiations after this commit (but here it is SslStream's fault since it doesn't handle interleaved messages correctly).
SSL_do_renegotiate, which now is removed, was also totally broken since OpenSSL will send an unexpected message if application data is received from that point, which could be data in the read buffer that the client has already sent.
The best thing would be if OpenSSL could fix their issues. This issue is known: http://rt.openssl.org/Ticket/Display.html?id=2481&user=guest&pass=guest since 2011 but they haven't fixed it yet...
I honestly wonder why postgres uses renegotiation at all. The motivation that cryptoanalysis is easier as more data is sent seems quite far-fetched. Since often the same session is used after renegotiation, the same master secret will still be used. Is there anyone that has successfully hacked a long ssl session by doing cryptoanalysis?
/Emil
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. And it's not just us. E.g. openssh also triggers renegotiations based on the amount of data sent. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
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. -- Florian Weimer / Red Hat Product Security
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. I'd say it is best to wait if and how OpenSSL change their API when they implement TLS 1.3. I'd vote against removing renegotiation. At the very least, if the feature should provide unnecessary and cumbersome with future versions of OpenSSL, we should retain ssl_renegotiation_limit and change the default to 0. It might still be of value with older versions. If changing the encryption is so useless, whe did the TLS workgroup decide to introduce rekeying as a substitute for renegotiation? Yours, Laurenz Albe
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
Renegotiation should be a best practice. Trouble is it's been broken (at the protocol level) three times in the last fewyears so it's a massive hole in practice. Ideally we should leave the renegotiate in, and only remove it if configure detects a broken version of TLS. Personal email. hbhotz@oxy.edu > On Feb 23, 2015, at 7:01 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: > > I'd say it is best to wait if and how OpenSSL change their API when they > implement TLS 1.3.
On 02/23/2015 04:01 PM, Albe Laurenz wrote: >> I think you could remove renegotiation from PostgreSQL as long as you >> offer something better than RC4 in the TLS handshake. > > I'd say it is best to wait if and how OpenSSL change their API when they > implement TLS 1.3. > > I'd vote against removing renegotiation. I'm just suggesting that the effort required to fix bugs in this part of PostgreSQL could be spent better elsewhere. > If changing the encryption is so useless, whe did the TLS workgroup > decide to introduce rekeying as a substitute for renegotiation? Theoretical considerations, mostly. If rekeying is strictly required after processing just a few petabytes, the cipher is severely broken and should no longer be used. -- Florian Weimer / Red Hat Product Security