Re: should libpq also require TLSv1.2 by default?

On Wed, Jun 24, 2020 at 9:50 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Yeah, and I would not be surprised to see cases where people complain
> to us about that when attempting to reach one of their old boxes,
> breaking some stuff they have been relying on for years by forcing the
> addition of a tls_min_server_protocol in the connection string. It is
> a more important step that we enforce TLSv1.2 on the server side
> actually, and libpq just follows up automatically with that.

I wonder how much of a problem this really is. A few quick Google
searches suggests that support for TLSv1.2 was added to OpenSSL in
v1.0.1, which was released in March 2012. If packagers adopted that
version for the following PostgreSQL release, they would have had
TLSv1.2 support from PostgreSQL 9.2 onward. Some people may have taken
longer to adopt it, but even if they waited a year or two, all
versions that they built with older OpenSSL versions would now be out
of support. It doesn't seem that likely that there are going to be
that many people using pg_dump to upgrade directly from PostgreSQL 9.2
-- or even 9.4 -- to PostgreSQL 13. Skipping six or eight major
versions in a single upgrade is a little unusual, in my experience.
And even if someone does want to do that, we haven't broken it; it'll
still work fine if they are connecting through a UNIX socket, and if
not, they can disable SSL or just specify that they're OK with an
older protocol version. That doesn't seem like a big deal, especially
if we can adopt Tom's suggestion of giving them a warning about what
went wrong.

Let's also consider the other side of this argument, which is that a
decent number of PostgreSQL users are operating in environments where
they are required for regulatory compliance to prohibit the use of
TLSv1.0 and TLSv1.1. Those people will be happy if that is the default
on both the client and the server side by default. They will probably
be somewhat happy anyway, because now we have an option for it, which
we didn't before. But they'll be more happy if it's the default. Now,
we can't please everybody here. Is it more important to please people
who would like insecure TLS versions disabled by default, or to please
people who want to use insecure TLS versions to back up old servers?
Seems debatable. Based on my own experience, I'd guess there are more
users who want to avoid insecure TLS versions than there are users who
want to use them to back up very old servers, so I'd tentatively favor
changing the default. However, I don't know whether my experiences are
representative.

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