Update minimum SSL version

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Update minimum SSL version

Peter Eisentraut-6
I propose to change the default of ssl_min_protocol_version to TLSv1.2
(from TLSv1, which means 1.0).  Older versions would still be supported,
just not by default.

The reason is that TLS 1.0 and 1.1 are either already discouraged or
deprecated or will be by the time PostgreSQL 13 comes out.  So this move
would be in the direction of "secure by default".  Specifically, PCI DSS
disallows the use of TLS 1.0 and discourages 1.1 [0], and browser
vendors are set to disable 1.0 and 1.1 in their products sometime soon [1].

Using TLS 1.2 requires OpenSSL 1.0.1, released in 2012.  I find this to
be satisfied in CentOS 6 and Debian jessie (oldoldstable), for example.

More details also in my recent blog post [2].


[0]:
https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
[1]:
https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/
[2]:
https://www.2ndquadrant.com/en/blog/setting-ssl-tls-protocol-versions-with-postgresql-12/

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

0001-Update-minimum-SSL-version.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Daniel Gustafsson
> On 29 Nov 2019, at 08:36, Peter Eisentraut <[hidden email]> wrote:
>
> I propose to change the default of ssl_min_protocol_version to TLSv1.2 (from TLSv1, which means 1.0).  Older versions would still be supported, just not by default.

+1 for having a sane default with a way to fall back to older versions in case
they are required.

cheers ./daniel

Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Magnus Hagander-2
On Fri, Nov 29, 2019 at 11:10 AM Daniel Gustafsson <[hidden email]> wrote:
> On 29 Nov 2019, at 08:36, Peter Eisentraut <[hidden email]> wrote:
>
> I propose to change the default of ssl_min_protocol_version to TLSv1.2 (from TLSv1, which means 1.0).  Older versions would still be supported, just not by default.

+1 for having a sane default with a way to fall back to older versions in case
they are required.

+1. As long as we still have support to change it down if needed, it's a good thing to ship with a proper default. 

--
Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Michael Paquier-2
On Fri, Nov 29, 2019 at 01:40:48PM +0100, Magnus Hagander wrote:
> +1. As long as we still have support to change it down if needed, it's a
> good thing to ship with a proper default.

+1.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Tom Lane-2
Michael Paquier <[hidden email]> writes:
> On Fri, Nov 29, 2019 at 01:40:48PM +0100, Magnus Hagander wrote:
>> +1. As long as we still have support to change it down if needed, it's a
>> good thing to ship with a proper default.

> +1.

What's the impact going to be on buildfarm members with older openssl
installations?  Perhaps "none", if they aren't running the ssl test
suite, but we should be clear about it.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Michael Paquier-2
On Fri, Nov 29, 2019 at 10:30:47AM -0500, Tom Lane wrote:
> What's the impact going to be on buildfarm members with older openssl
> installations?  Perhaps "none", if they aren't running the ssl test
> suite, but we should be clear about it.

The buildfarm logs don't directly report the version of OpenSSL used
as far as I recalled, and a quick lookup shows that..  Anyway, I
recall that all Windows buildfarm members linking to OpenSSL use at
least 1.0.2 on HEAD.  For the others, I would be ready to suspect that
some of them are still using 0.9.8 and 1.0.0.

Anyway, as we still support OpenSSL down to 0.9.8 on HEAD, shouldn't
we just patch the SSL TAP tests to make sure that we don't enforce an
incorrect minimum version at configuration time?

[... thinks more ...]

Actually, no, what I am writing here is incorrect.  We should make
sure of that the default configuration is correct at initdb time, and
the patch does not do that.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Tom Lane-2
Michael Paquier <[hidden email]> writes:
> On Fri, Nov 29, 2019 at 10:30:47AM -0500, Tom Lane wrote:
>> What's the impact going to be on buildfarm members with older openssl
>> installations?  Perhaps "none", if they aren't running the ssl test
>> suite, but we should be clear about it.

> Actually, no, what I am writing here is incorrect.  We should make
> sure of that the default configuration is correct at initdb time, and
> the patch does not do that.

Yeah, that's sort of what I was getting at, but not quite.  On newer
openssl versions, this doesn't seem like it's really changing anything
at all --- AFAIK, the client and server will already negotiate the
highest jointly-supported TLS version.  OTOH, with an openssl version
old enough to not understand TLS >= 1.2, this change likewise won't do
anything, except break configurations that used to work (for some
not-too-secure value of "work").

I think the real question we have to answer is this: are we intent on
making people upgrade ancient openssl installations?  If so, shouldn't
we be doing something even more aggressive than this?  If not, wouldn't
the patch need to try to autoconfigure the minimum TLS version?  As
proposed, the patch seems to be somewhere in a passive-aggressive middle
ground of being annoying without really enforcing anything.  So I don't
quite see the point.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Peter Eisentraut-6
In reply to this post by Tom Lane-2
On 2019-11-29 16:30, Tom Lane wrote:

> Michael Paquier <[hidden email]> writes:
>> On Fri, Nov 29, 2019 at 01:40:48PM +0100, Magnus Hagander wrote:
>>> +1. As long as we still have support to change it down if needed, it's a
>>> good thing to ship with a proper default.
>
>> +1.
>
> What's the impact going to be on buildfarm members with older openssl
> installations?  Perhaps "none", if they aren't running the ssl test
> suite, but we should be clear about it.

If they aren't running the ssl tests, then none.

We could add an override of ssl_min_protocol_version in
src/test/ssl/t/SSLServer.pm so that the tests still work with very old
OpenSSL versions by default.  That might be a good idea.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Peter Eisentraut-6
In reply to this post by Tom Lane-2
On 2019-11-30 04:06, Tom Lane wrote:
> I think the real question we have to answer is this: are we intent on
> making people upgrade ancient openssl installations?  If so, shouldn't
> we be doing something even more aggressive than this?  If not, wouldn't
> the patch need to try to autoconfigure the minimum TLS version?  As
> proposed, the patch seems to be somewhere in a passive-aggressive middle
> ground of being annoying without really enforcing anything.  So I don't
> quite see the point.

The trade-off is that this makes the defaults better for the vast
majority of users and gives users of really old systems a nudge that
they are no longer in compliance with industry best practices.  You need
manual steps to set up SSL anyway, so this doesn't introduce an entirely
new kind of requirement for the latter group of users.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Daniel Gustafsson
In reply to this post by Michael Paquier-2
> On 30 Nov 2019, at 03:43, Michael Paquier <[hidden email]> wrote:
>
> On Fri, Nov 29, 2019 at 10:30:47AM -0500, Tom Lane wrote:
>> What's the impact going to be on buildfarm members with older openssl
>> installations?  Perhaps "none", if they aren't running the ssl test
>> suite, but we should be clear about it.
>
> The buildfarm logs don't directly report the version of OpenSSL used
> as far as I recalled, and a quick lookup shows that..

Not explicitly, but it would be a nice if it did.  Since the version depends on
the optional FIPS module, running "openssl version" is really the safe option,
which in itself is hard since the libraries pointed to with --with-libs aren't
guaranteed to have an openssl command installed etc.  OpenSSL might also these
days be LibreSSL (or potentially even BoringSSL perhaps if someone twists the
arm of their installation enough).

However, looking at the signatures detected by autoconf we can however get an
idea of which version is used.  SSL_clear_options and X509_get_signature_nid()
first shipped in 1.0.2, while SSL_get_current_compression first shipped in
0.9.8.  There are also a set of functions which are new in 1.1.0 (BIO_get_data
et.al).

This tells us that for example alewife is likely running 1.0.2:

checking for SSL_new in -lssl... (cached) yes
checking for SSL_clear_options... (cached) no
checking for SSL_get_current_compression... (cached) yes
checking for X509_get_signature_nid... (cached) yes
checking for OPENSSL_init_ssl... (cached) no
checking for BIO_get_data... (cached) no
checking for BIO_meth_new... (cached) no
checking for ASN1_STRING_get0_data... (cached) no

(the careful observer notes that the SSL_clear_options() check fails even
though it should be in 1.0.2, and thats probably because SSL_clear_options is a
macro until 1.1.0 where it becomes a function).

gaur however looks like it is running 0.9.8:

checking for SSL_new in -lssl... yes
checking for SSL_clear_options... no
checking for SSL_get_current_compression... yes
checking for X509_get_signature_nid... no
checking for OPENSSL_init_ssl... no
checking for BIO_get_data... no
checking for BIO_meth_new... no
checking for ASN1_STRING_get0_data... no
checking for CRYPTO_lock... yes

scorpionfly running OpenBSD 6.6 configures as a LibreSSL on par with what we
expect for 1.1.0 (SSL_clear_options again fail here since it's still a macro in
LibreSSL):

checking for SSL_new in -lssl... (cached) yes
checking for SSL_clear_options... (cached) no
checking for SSL_get_current_compression... (cached) yes
checking for X509_get_signature_nid... (cached) yes
checking for OPENSSL_init_ssl... (cached) yes
checking for BIO_get_data... (cached) yes
checking for BIO_meth_new... (cached) yes
checking for ASN1_STRING_get0_data... (cached) yes
checking for CRYPTO_lock... (cached) yes

Randomly picking animals, and trying to target platforms where older versions
could be expected, I didn't see any <= 0.9.7; a small number 0.9.8 and most at
1.0.2 or higher (with the 0.9.8 animals being: gaur, sungazer and prairiedog).
This is not an exhaustive list of course, maybe someone with better access to
the buildfarm data can do some more clever analysis.

cheers ./daniel

Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Tom Lane-2
Daniel Gustafsson <[hidden email]> writes:
> On 30 Nov 2019, at 03:43, Michael Paquier <[hidden email]> wrote:
>> The buildfarm logs don't directly report the version of OpenSSL used
>> as far as I recalled, and a quick lookup shows that..

> Not explicitly, but it would be a nice if it did.  Since the version depends on
> the optional FIPS module, running "openssl version" is really the safe option,
> which in itself is hard since the libraries pointed to with --with-libs aren't
> guaranteed to have an openssl command installed etc.  OpenSSL might also these
> days be LibreSSL (or potentially even BoringSSL perhaps if someone twists the
> arm of their installation enough).

Yeah, I do not think that would be a good solution --- it would give wrong
answers on three of my four buildfarm animals :-(, for precisely the
reason that they're using --with-libs to point to a non-system openssl
installation.

Is there a simple way to ask the library itself for version info?
It might be worth the cycles to have configure run a small test
program to extract and print that data (not on cross-compile
builds, of course).

> (the careful observer notes that the SSL_clear_options() check fails even
> though it should be in 1.0.2, and thats probably because SSL_clear_options is a
> macro until 1.1.0 where it becomes a function).

Hmm, is it worth the trouble to fix that?

> gaur however looks like it is running 0.9.8:

gaur and prairiedog are both building with 0.9.8x, as you can tell
from their --with-libs options.

> Randomly picking animals, and trying to target platforms where older versions
> could be expected, I didn't see any <= 0.9.7; a small number 0.9.8 and most at
> 1.0.2 or higher (with the 0.9.8 animals being: gaur, sungazer and prairiedog).

According to the commit log (see 593d4e47d), we require 0.9.8 or later
in v10 and up, so any older animals got upgraded or retired some time
ago.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Tom Lane-2
In reply to this post by Peter Eisentraut-6
Peter Eisentraut <[hidden email]> writes:
> On 2019-11-30 04:06, Tom Lane wrote:
>> I think the real question we have to answer is this: are we intent on
>> making people upgrade ancient openssl installations?

> The trade-off is that this makes the defaults better for the vast
> majority of users and gives users of really old systems a nudge that
> they are no longer in compliance with industry best practices.  You need
> manual steps to set up SSL anyway, so this doesn't introduce an entirely
> new kind of requirement for the latter group of users.

True.  I'm okay with this as long as we adapt the ssl test suite as
per your other reply.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Daniel Gustafsson
In reply to this post by Tom Lane-2
> On 2 Dec 2019, at 15:59, Tom Lane <[hidden email]> wrote:

> Is there a simple way to ask the library itself for version info?
> It might be worth the cycles to have configure run a small test
> program to extract and print that data (not on cross-compile
> builds, of course).

Asking the lib is easy, making that fit cleanly into how autoconf does things might be trickier. I’ll take a look and will report back (on the SSL_clear_options thing as well).

cheers ./daniel


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Robert Haas
In reply to this post by Michael Paquier-2
On Fri, Nov 29, 2019 at 9:44 PM Michael Paquier <[hidden email]> wrote:
> Actually, no, what I am writing here is incorrect.  We should make
> sure of that the default configuration is correct at initdb time, and
> the patch does not do that.

I think that would be overkill. There shouldn't be many people who are
running with a version of PostgreSQL that is 8 years newer than the
version of OpenSSL they are using, and who are also relying on SSL,
and even if there are such people, it's a pretty minor configuration
change to make it work. However, it would be worth putting in some
effort to make sure that we give a good error message if this happens.
I'm not sure how practical that is. But there's a big difference
between giving an incomprehensible OpenSSL message that says "things
aren't working and good luck figuring out why" and giving a message
that says something like:

ERROR: ssl_min_protocol_version specifies TLSv1.2, but your OpenSSL
library does not support protocol versions beyond TLSv1.1

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Tom Lane-2
Robert Haas <[hidden email]> writes:
> ... However, it would be worth putting in some
> effort to make sure that we give a good error message if this happens.

That's an excellent point, but it looks like we're pretty good
already.  I tried the patch with openssl 0.9.8x, and got this
failure at server start:

FATAL:  ssl_min_protocol_version setting TLSv1.2 not supported by this build

Maybe it'd be worth extending that to show the max supported
version, with some rats-nest of #ifdefs, but I'm not sure if
it's worth the trouble.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Robert Haas
On Mon, Dec 2, 2019 at 11:39 AM Tom Lane <[hidden email]> wrote:
> That's an excellent point, but it looks like we're pretty good
> already.  I tried the patch with openssl 0.9.8x, and got this
> failure at server start:
>
> FATAL:  ssl_min_protocol_version setting TLSv1.2 not supported by this build

Oh, that's pretty good.

> Maybe it'd be worth extending that to show the max supported
> version, with some rats-nest of #ifdefs, but I'm not sure if
> it's worth the trouble.

Especially if we mess up the #ifdefs. :-)

I don't have super-strong feelings that we have to try to do that. It
would be worth doing if it were easy, I think, but if our hypothesis
that this will affect relatively few people is correct, it may not
matter very much.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Tom Lane-2
Robert Haas <[hidden email]> writes:
> On Mon, Dec 2, 2019 at 11:39 AM Tom Lane <[hidden email]> wrote:
>> Maybe it'd be worth extending that to show the max supported
>> version, with some rats-nest of #ifdefs, but I'm not sure if
>> it's worth the trouble.

> Especially if we mess up the #ifdefs. :-)

Yah.  Although, looking at the code in be-secure-openssl.c,
it doesn't look that hard to do in an extensible way.
Something like (untested)

 static int
 ssl_protocol_version_to_openssl(int v, const char *guc_name, int loglevel)
 {
     switch (v)
     {
         case PG_TLS_ANY:
             return 0;
         case PG_TLS1_VERSION:
+#define PG_MAX_TLS_VERSION "TLSv1"
             return TLS1_VERSION;
         case PG_TLS1_1_VERSION:
 #ifdef TLS1_1_VERSION
+#undef PG_MAX_TLS_VERSION
+#define PG_MAX_TLS_VERSION "TLSv1.1"
             return TLS1_1_VERSION;
 #else
             break;
 #endif
         case PG_TLS1_2_VERSION:
 #ifdef TLS1_2_VERSION
+#undef PG_MAX_TLS_VERSION
+#define PG_MAX_TLS_VERSION "TLSv1.2"
             return TLS1_2_VERSION;
 #else
             break;
 #endif
         case PG_TLS1_3_VERSION:
 #ifdef TLS1_3_VERSION
+#undef PG_MAX_TLS_VERSION
+#define PG_MAX_TLS_VERSION "TLSv1.3"
             return TLS1_3_VERSION;
 #else
             break;
 #endif
     }
 
     ereport(loglevel,
             (errmsg("%s setting %s not supported by this build",
                     guc_name,
-                    GetConfigOption(guc_name, false, false))));
+                    GetConfigOption(guc_name, false, false)),
+             errdetail("Maximum supported TLS version is %s.",
+                       PG_MAX_TLS_VERSION)));
     return -1;
 }

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Michael Paquier-2
In reply to this post by Tom Lane-2
On Mon, Dec 02, 2019 at 09:59:44AM -0500, Tom Lane wrote:
> Is there a simple way to ask the library itself for version info?
> It might be worth the cycles to have configure run a small test
> program to extract and print that data (not on cross-compile
> builds, of course).

SSLeay_version():
https://www.openssl.org/docs/man1.0.2/man3/SSLeay_version.html
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Michael Paquier-2
In reply to this post by Tom Lane-2
On Mon, Dec 02, 2019 at 12:51:26PM -0500, Tom Lane wrote:
> Yah.  Although, looking at the code in be-secure-openssl.c,
> it doesn't look that hard to do in an extensible way.
> Something like (untested)

While we are on the topic...  Here is another wild idea.  We discussed
not so long ago about removing support for OpenSSL 0.9.8 from the
tree.  What if we removed support for 1.0.0 and 0.9.8 for 13~.  This
would solve a couple of compatibility headaches, and we have TLSv1.2
support automatically for all the versions supported.  Note that 1.0.0
has been retired by upstream in February 2014.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update minimum SSL version

Magnus Hagander-2
On Tue, Dec 3, 2019 at 4:53 AM Michael Paquier <[hidden email]> wrote:
On Mon, Dec 02, 2019 at 12:51:26PM -0500, Tom Lane wrote:
> Yah.  Although, looking at the code in be-secure-openssl.c,
> it doesn't look that hard to do in an extensible way.
> Something like (untested)

While we are on the topic...  Here is another wild idea.  We discussed
not so long ago about removing support for OpenSSL 0.9.8 from the
tree.  What if we removed support for 1.0.0 and 0.9.8 for 13~.  This
would solve a couple of compatibility headaches, and we have TLSv1.2
support automatically for all the versions supported.  Note that 1.0.0
has been retired by upstream in February 2014.

Is 1.0.1 considered a separate major from 1.0.0, in this reasoning? Because while retiring 1.0.0 should probably not be that terrible, 1.0.1 is still in very widespread use on most long term supported distributions.

--
12