Re: should libpq also require TLSv1.2 by default? - Mailing list pgsql-hackers
From | Daniel Gustafsson |
---|---|
Subject | Re: should libpq also require TLSv1.2 by default? |
Date | |
Msg-id | 003BDF1F-FC7A-4901-BBC0-33A44FE07A89@yesql.se Whole thread Raw |
In response to | Re: should libpq also require TLSv1.2 by default? (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Responses |
Re: should libpq also require TLSv1.2 by default?
|
List | pgsql-hackers |
> On 24 Jun 2020, at 19:57, Peter Eisentraut <peter.eisentraut@2ndquadrant.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 settingnamed ssl_min_protocol_version to libpq. But AFAICT, the default value of the libpq setting is empty, so any protocolversion 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 changebut 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, thatTLSv1.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
pgsql-hackers by date: