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).

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.

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.

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

(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?

(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.

My bad. The CVE patch had nothing to do with the server code. It has always been that way.

(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

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.

(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

(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

(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?

(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?

(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.

(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.

Created attachment 1104407 [details]
patch for rhel6

Here is patch for RHEL6

Comment on attachment 1104407 [details]
patch for rhel6

Yes, that should work.

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