SSL renegotiation
Hi.
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
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Renegotiation should be a best practice. Trouble is it's been broken (at the protocol level) three times in the last few years 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers