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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: should libpq also require TLSv1.2 by default?
Date: 2020-06-24 22:30:03
Message-ID: 003BDF1F-FC7A-4901-BBC0-33A44FE07A89@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 24 Jun 2020, at 19:57, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> On 2020-06-24 10:33, Daniel Gustafsson wrote:
>>> In PG13, we raised the server-side default of ssl_min_protocol_version to TLSv1.2. We also added a connection setting named ssl_min_protocol_version to libpq. But AFAICT, the default value of the libpq setting is empty, so any protocol version will be accepted. Is this what we wanted? Should we raise the default in libpq as well?
>> This was discussed [0] when the connection settings were introduced, and the
>> concensus was to leave them alone [1] to allow for example a new pg_dump to
>> work against an old server. Re-reading the thread I think the argument still
>> holds, but I was about to respond "yes, let's do this" before refreshing my
>> memory. Perhaps we should add a comment explaining this along the lines of the
>> attached?
>> [0] https://www.postgresql.org/message-id/157800160408.1198.1714906047977693148.pgcf%40coridan.postgresql.org
>> [1] https://www.postgresql.org/message-id/31993.1578321474%40sss.pgh.pa.us
>
> ISTM that these discussions went through the same questions and arguments that were made regarding the server-side change but arrived at a different conclusion. So I suggest to reconsider this so that we don't ship with contradictory results.

I don't think anyone argues against safe defaults for communication between
upgraded clients and upgraded servers. That being said; out of the box, an
upgraded client *will* use TLSv1.2 when connecting to a upgraded server due to
the server defaults requirements (assuming the server hasn't been reconfigured
with a lower TLS version, but since we're talking defaults we have to assume
that).

The problem comes when an updated client needs to talk to an old server which
hasn't been upgraded and which use an older OpenSSL version. If we set TLSv1.2
as the minimum client version, the user will have to amend a connection string
which used to work when talking to a server which hasn't changed. If we don't
raise the default, a user to wants nothing lower than TLSv1.2 will have to
amend the connection string.

> That doesn't necessarily mean that we have to make a change, but we should make sure our rationale is sound.

Totally agree. I think I, FWIW, still vote for keeping it at 1.0 to not break
connections to old servers, since upgraded/new servers will enforce 1.2
anyways.

As mentioned elsewhere in the thread, maybe this is also something which can be
done more easily if we improve the error reporting? Right now it's fairly
cryptic IMO.

> Note that all OpenSSL versions that do not support TLSv1.2 also do not support TLSv1.1. So by saying, in effect, that TLSv1.2 is too new to require, we are saying that we need to keep supporting TLSv1.0 -- which is heavily deprecated. Also note that the first OpenSSL version with support for TLSv1.2 shipped on March 14, 2012.

Correct, this being the 1.0.1 release which is referred to.

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2020-06-24 22:31:00 Re: Why forbid "INSERT INTO t () VALUES ();"
Previous Message Jesse Zhang 2020-06-24 22:11:03 Strange behavior with polygon and NaN