Bug 1287053 - PostgreSQL is limited to using obsoleted security protocols
PostgreSQL is limited to using obsoleted security protocols
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: postgresql (Show other bugs)
6.7
All All
high Severity high
: pre-dev-freeze
: 6.8
Assigned To: Pavel Raiskup
Jakub Prokes
:
Depends On:
Blocks: 1057564 1253743 1310222
  Show dependency treegraph
 
Reported: 2015-12-01 06:59 EST by Hubert Kario
Modified: 2016-05-10 21:33 EDT (History)
10 users (show)

See Also:
Fixed In Version: postgresql-8.4.20-6.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 21:33:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for rhel6 (779 bytes, patch)
2015-12-10 11:19 EST, Pavel Kajaba
tmraz: review+
Details | Diff

  None (edit)
Description Hubert Kario 2015-12-01 06:59:30 EST
Description of problem:
As described on https://access.redhat.com/articles/1462873 and https://access.redhat.com/articles/1472953 postgresql clients and servers cannot be made to negotiate protocol versions higher than TLSv1.0.

This protocol version has had multiple weaknesses discovered since it was published last century. Both the general recommendation[1] and our own[2] is that implementations SHOULD NOT negotiate TLS version 1.0.

Version-Release number of selected component (if applicable):
8.4.20-2.el6_6

How reproducible:
Always

Steps to Reproduce:
1. Try to find setting to enable TLSv1.2 support

Actual results:
No setting available

Expected results:
TLS v1.2 available by default and negotiated if supported by both sides.

Additional info:
 1 - https://tools.ietf.org/html/bcp195#section-3.1
 2 - https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Security_Guide/index.html#sec-Choosing_Algorithms_to_Enable
Comment 1 Pavel Raiskup 2015-12-01 07:58:14 EST
Hubert, it look like fixed in PostgreSQL >= v9.0, is that right?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c6b7b9a9cef

If that is truth, both postgresql92-postgresql and rh-postgresql94-postgresql
packages are fine (and RHEL7 too).
Comment 2 Hubert Kario 2015-12-01 09:51:21 EST
yes, the following parts:

    ...
    SSL_context = SSL_CTX_new(SSLv23_method());
    ...
    SSL_CTX_set_options(SSL_context, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
    ...

is what is needed to fix this.
Comment 3 Hubert Kario 2015-12-01 09:59:17 EST
Though note that there may be TLS terminators or accelerators used by servers that are intolerant to higher protocol versions so the configuration file should be extended to allow the administrator to disable the higher protocol versions if necessary, or to disable lower protocol versions if he or she deems them not secure enough.
Comment 4 Martin Poole 2015-12-03 09:03:19 EST
Current build of postgresql (postgresql-8.4.20-4.el6_7) has the following issues

The client side only performs TLSv1 connections (src/interfaces/libpq/fe-secure.c)

                SSL_context = SSL_CTX_new(TLSv1_method());


server side has the following problem (src/backend/libpq/be-secure.c)

        /* set up empheral DH keys */
        SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
        SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2);

which counts as a regression caused by postgresql-CVE-2015-3165.patch


Current build of postgresql92-postgresql has the following issues.

The client side appears ok (src/interfaces/libpq/fe-secure.c)

but the server side has the following (src/backend/libpq/be-secure.c)

        /* set up ephemeral DH keys, and disallow SSL v2 while at it */
        SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
        SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2);


So in theory allows SSLv3 connections with no mechanism to disable.



rh-postgresql94-postgresql is better in that both the client and server are moderately sane, following being the server-side equivalent to the above

        /* set up ephemeral DH keys, and disallow SSL v2/v3 while at it */
        SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
        SSL_CTX_set_options(SSL_context,
                                        SSL_OP_SINGLE_DH_USE |
                                        SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);



None of the code present allows for the disabling of any TLS protocol
Comment 5 Pavel Raiskup 2015-12-03 09:43:19 EST
(In reply to Martin Poole from comment #4)
> Current build of postgresql (postgresql-8.4.20-4.el6_7) has the following
> issues
[...]
> server side has the following problem (src/backend/libpq/be-secure.c)
> 
>         /* set up empheral DH keys */
>         SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
>         SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE |
> SSL_OP_NO_SSLv2);
> 
> which counts as a regression caused by postgresql-CVE-2015-3165.patch

What hunk from postgresql-CVE-2015-3165.patch makes you think this is
regression?
Comment 6 Pavel Raiskup 2015-12-03 09:44:54 EST
(In reply to Martin Poole from comment #4)
> None of the code present allows for the disabling of any TLS protocol

These sort of things is something which we need to have upstream first.
Comment 8 Martin Poole 2015-12-03 10:38:02 EST
My bad. The CVE patch had nothing to do with the server code. It has always been that way.
Comment 10 Pavel Raiskup 2015-12-09 06:09:26 EST
(In reply to Martin Poole from comment #4)
> Current build of postgresql (postgresql-8.4.20-4.el6_7) has the following
> issues
[snip]
> server side has the following problem (src/backend/libpq/be-secure.c)
> 
>         /* set up empheral DH keys */
>         SSL_CTX_set_tmp_dh_callback(SSL_context, tmp_dh_cb);
>         SSL_CTX_set_options(SSL_context, SSL_OP_SINGLE_DH_USE |
> SSL_OP_NO_SSLv2);

I'm afraid we do not want to disable SSLv3 for everybody on the server side --
as some clients might already depend on it -- and it could result in
regression.  9.4 has SSLv3 disabled, but those servers don't have to keep 100%
compatibility with older clients.

This is how upstream decided to go forward with older supported PostgreSQL
versions -- we should not differ our server from the rest of the world.

(In reply to Hubert Kario from comment #3)
> Though note that there may be TLS terminators or accelerators used by
> servers that are intolerant to higher protocol versions so the configuration
> file should be extended to allow the administrator to disable the higher
> protocol versions if necessary, or to disable lower protocol versions if he
> or she deems them not secure enough.

I'm not sure how TLS terminators work to decide:  but if disabling of SSLv3
_is_ a concern, can those terminators be used?  That would let us to do the
right thing -- avoiding regressions in old RHEL6's PostgreSQL 8.4 in Y2016.

Pavel
Comment 11 Hubert Kario 2015-12-09 06:35:56 EST
By terminators I meant an appliance sitting before PostgreSQL, offloading TLS to separate hardware - I don't know how common is such config, but it is technically possible.

We can disable SSLv3 support by default under the banner of a security fix. *But* if we do that, we must allow users to override our decision and turn support for SSLv3 back on through a config option, so that they have to downgrade a package to get functionality back. This of course makes the fix more complex.
Comment 12 Pavel Raiskup 2015-12-09 06:53:14 EST
(In reply to Hubert Kario from comment #11)
> By terminators I meant an appliance sitting before PostgreSQL, offloading
> TLS to separate hardware - I don't know how common is such config, but it is
> technically possible.

Yeah, sounds like some TLS proxy without separate hardware is technically
possible too.  Thanks.

> We can disable SSLv3 support by default under the banner of a security fix.
> *But* if we do that, we must allow users to override our decision and turn
> support for SSLv3 back on through a config option, so that they have to
> downgrade a package to get functionality back. This of course makes the fix
> more complex.

I agree, but I don't like the idea of inventing new configuration option
downstream-only.  That _would have to be_ solved in postgresql master first to
let us know that we are not going to support RHEL downstream feature forever.

Have you, Hubert, tried to contact OpenSSL upstream to try to invent new API
allowing us to set SSL/TLS set of versions usable for SSL_CTX?  I mean
something like 'SSL_CTX_set_cipher_list()' (which takes pretty standardized
string), but with available '!TLSv1.0', '!SSLv3', etc.?  Having per-project
configuration options (e.g. postgresql.conf in case of PostgreSQL) doing this
manually all the time does not sound like good approach.  Why is this like
that?

Pavel
Comment 13 Hubert Kario 2015-12-09 07:19:49 EST
(In reply to Pavel Raiskup from comment #12)
> > We can disable SSLv3 support by default under the banner of a security fix.
> > *But* if we do that, we must allow users to override our decision and turn
> > support for SSLv3 back on through a config option, so that they have to
> > downgrade a package to get functionality back. This of course makes the fix
> > more complex.
> 
> I agree, but I don't like the idea of inventing new configuration option
> downstream-only.  That _would have to be_ solved in postgresql master first
> to
> let us know that we are not going to support RHEL downstream feature forever.

agreed, and that's why unfortunately leaving SSLv3 in is least bad.
 
> Have you, Hubert, tried to contact OpenSSL upstream to try to invent new API
> allowing us to set SSL/TLS set of versions usable for SSL_CTX?  I mean
> something like 'SSL_CTX_set_cipher_list()' (which takes pretty standardized
> string), but with available '!TLSv1.0', '!SSLv3', etc.?  Having per-project
> configuration options (e.g. postgresql.conf in case of PostgreSQL) doing this
> manually all the time does not sound like good approach.  Why is this like
> that?

Actually it already is upstream, unfortunately it is OpenSSL 1.0.2 and later only, we have not backported it to RHEL.

See SSL_CONF_cmd(3)[1] and mod_ssl SSLOpenSSLConfCmd[2] directive for usage example.
 
 1 - https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html
 2 - https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd
Comment 14 Pavel Raiskup 2015-12-09 08:00:42 EST
(In reply to Hubert Kario from comment #13)
> (In reply to Pavel Raiskup from comment #12)
> > > We can disable SSLv3 support by default under the banner of a security
> > > fix.  *But* if we do that, we must allow users to override our decision
> > > and turn support for SSLv3 back on through a config option, so that they
> > > have to downgrade a package to get functionality back. This of course
> > > makes the fix more complex.
> > 
> > I agree, but I don't like the idea of inventing new configuration option
> > downstream-only.  That _would have to be_ solved in postgresql master
> > first to let us know that we are not going to support RHEL downstream
> > feature forever.
> 
> agreed, and that's why unfortunately leaving SSLv3 in is least bad.

Can you elaborate on this please?  Upstream disabled SSLv3 in latest major
versions, but for compatibility reasons in older servers (up to 9.3) they do
accept SSLv3.

Do you mean "leaving the SSLv3 _in RHEL6_ is at least bad", but removing it's
support could be even worse?  Or do you think that we _really_ should remove
SSLv3 support in RHEL6's PostgreSQL?

> > Have you, Hubert, tried to contact OpenSSL upstream to try to invent new
> > API allowing us to set SSL/TLS set of versions usable for SSL_CTX?  I mean
> > something like 'SSL_CTX_set_cipher_list()' (which takes pretty
> > standardized string), but with available '!TLSv1.0', '!SSLv3', etc.?
> > Having per-project configuration options (e.g. postgresql.conf in case of
> > PostgreSQL) doing this manually all the time does not sound like good
> > approach.  Why is this like that?
> 
> Actually it already is upstream, unfortunately it is OpenSSL 1.0.2 and later
> only, we have not backported it to RHEL.

And could we?

> See SSL_CONF_cmd(3)[1] and mod_ssl SSLOpenSSLConfCmd[2] directive for usage
> example.
>  
>  1 - https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html
>  2 - https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd

Thanks for the links!  While this is available these days, I really doubt
upstream would accept patch inventing PostgreSQL specific configuration like
no_sslv3 = true, or 'tls_versions = -no_ssl2' into postgresql.conf.  We could
expect something like 'ssl_conf_cmd = XXXX' could be supported, while
PostgreSQL would just pass the XXXX string down to ssl without parsing.
This approach would be almost trival to backport down to RHEL6, but would
require SSLOpenSSLConfCmd available in openssl, of course.  So is the
backport realistic?
Comment 15 Hubert Kario 2015-12-09 08:18:17 EST
(In reply to Pavel Raiskup from comment #14)
> (In reply to Hubert Kario from comment #13)
> > (In reply to Pavel Raiskup from comment #12)
> > > > We can disable SSLv3 support by default under the banner of a security
> > > > fix.  *But* if we do that, we must allow users to override our decision
> > > > and turn support for SSLv3 back on through a config option, so that they
> > > > have to downgrade a package to get functionality back. This of course
> > > > makes the fix more complex.
> > > 
> > > I agree, but I don't like the idea of inventing new configuration option
> > > downstream-only.  That _would have to be_ solved in postgresql master
> > > first to let us know that we are not going to support RHEL downstream
> > > feature forever.
> > 
> > agreed, and that's why unfortunately leaving SSLv3 in is least bad.
> 
> Can you elaborate on this please?  Upstream disabled SSLv3 in latest major
> versions, but for compatibility reasons in older servers (up to 9.3) they do
> accept SSLv3.
> 
> Do you mean "leaving the SSLv3 _in RHEL6_ is at least bad", but removing it's
> support could be even worse?  Or do you think that we _really_ should remove
> SSLv3 support in RHEL6's PostgreSQL?

removing its support without the user being able to override means it's a regression - we need to announce them ahead of time to customers
 
> > > Have you, Hubert, tried to contact OpenSSL upstream to try to invent new
> > > API allowing us to set SSL/TLS set of versions usable for SSL_CTX?  I mean
> > > something like 'SSL_CTX_set_cipher_list()' (which takes pretty
> > > standardized string), but with available '!TLSv1.0', '!SSLv3', etc.?
> > > Having per-project configuration options (e.g. postgresql.conf in case of
> > > PostgreSQL) doing this manually all the time does not sound like good
> > > approach.  Why is this like that?
> > 
> > Actually it already is upstream, unfortunately it is OpenSSL 1.0.2 and later
> > only, we have not backported it to RHEL.
> 
> And could we?

I don't think so.

Tomas?
Comment 16 Pavel Raiskup 2015-12-09 08:23:11 EST
(In reply to Hubert Kario from comment #15)
> (In reply to Pavel Raiskup from comment #14)
> > (In reply to Hubert Kario from comment #13)
> > > agreed, and that's why unfortunately leaving SSLv3 in is least bad.
> > 
> > Can you elaborate on this please?  Upstream disabled SSLv3 in latest major
> > versions, but for compatibility reasons in older servers (up to 9.3) they do
> > accept SSLv3.
> > 
> > Do you mean "leaving the SSLv3 _in RHEL6_ is at least bad", but removing it's
> > support could be even worse?  Or do you think that we _really_ should remove
> > SSLv3 support in RHEL6's PostgreSQL?
> 
> removing its support without the user being able to override means it's a
> regression - we need to announce them ahead of time to customers

Sorry, my bad.  I've read 'at least bad' but you said 'least bad' - Ack.
Comment 17 Tomas Mraz 2015-12-10 05:27:03 EST
(In reply to Hubert Kario from comment #15)
> > > > Have you, Hubert, tried to contact OpenSSL upstream to try to invent new
> > > > API allowing us to set SSL/TLS set of versions usable for SSL_CTX?  I mean
> > > > something like 'SSL_CTX_set_cipher_list()' (which takes pretty
> > > > standardized string), but with available '!TLSv1.0', '!SSLv3', etc.?
> > > > Having per-project configuration options (e.g. postgresql.conf in case of
> > > > PostgreSQL) doing this manually all the time does not sound like good
> > > > approach.  Why is this like that?
> > > 
> > > Actually it already is upstream, unfortunately it is OpenSSL 1.0.2 and later
> > > only, we have not backported it to RHEL.
> > 
> > And could we?
> 
> I don't think so.
> 
> Tomas?

Yes, backporting this support would be fairly non-trivial and risky. I'd have to think about it more whether there are or aren't any obstacles that would make it completely impossible though.
Comment 18 Pavel Kajaba 2015-12-10 11:19 EST
Created attachment 1104407 [details]
patch for rhel6

Here is patch for RHEL6
Comment 19 Tomas Mraz 2015-12-11 03:32:01 EST
Comment on attachment 1104407 [details]
patch for rhel6

Yes, that should work.
Comment 30 errata-xmlrpc 2016-05-10 21:33:29 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0978.html

Note You need to log in before you can comment on or make changes to this bug.