Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joabT-0003I8-1X for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2020 22:44:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1joabQ-00062h-Ao for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Jun 2020 22:44:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joabQ-00062a-2k for pgsql-hackers@lists.postgresql.org; Thu, 25 Jun 2020 22:44:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joabN-0007t8-CE for pgsql-hackers@postgresql.org; Thu, 25 Jun 2020 22:44:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 05PMi50T2305872; Thu, 25 Jun 2020 18:44:07 -0400 From: Tom Lane To: Daniel Gustafsson cc: Magnus Hagander , Peter Eisentraut , pgsql-hackers Subject: Re: should libpq also require TLSv1.2 by default? In-reply-to: References: <4FBC50DB-599A-42AA-90C8-3051E3A748BB@yesql.se> Comments: In-reply-to Daniel Gustafsson message dated "Wed, 24 Jun 2020 11:01:48 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2305870.1593125045.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2020 18:44:05 -0400 Message-ID: <2305871.1593125045@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Daniel Gustafsson writes: >> On 24 Jun 2020, at 10:46, Magnus Hagander wrote: >> It might also be worth noting that it's not really "any protocol versio= n", it means it will be "whatever the openssl configuration says", I think= ? For example, debian buster sets: >> = >> [system_default_sect] >> MinProtocol =3D TLSv1.2 >> = >> Which I believe means that if your libpq app is running on debian buste= r, it will be min v1.2 already > Correct, that being said I'm not sure how common it is for distributions= to set > a default protocol version. The macOS versions I have handy doesn't enf= orce a > default version, nor does Ubuntu 20.04, FreeBSD 12 or OpenBSD 6.5 AFAICT= . Yeah, this. I experimented with connecting current libpq to a 9.2-vintage server I'd built with openssl 0.9.8x, and was surprised to find I couldn't do so unless I explicitly set "ssl_min_protocol_version=3Dtlsv1". After some digging I verified that that's because RHEL8's openssl.cnf sets MinProtocol =3D TLSv1.2 MaxProtocol =3D TLSv1.3 Interestingly, Fedora 32 is laxer: MinProtocol =3D TLSv1 MaxProtocol =3D TLSv1.3 I concur with Daniel's finding that current macOS and FreeBSD don't enforce anything in this area. Nonetheless, for a pretty significant fraction of the world, our claim that the default is to not enforce any minimum protocol version is a lie. My feeling now is that we'd be better off defaulting ssl_min_protocol_version to something nonempty, just to make this behavior platform-independent. We certainly can't leave the docs as they are. Also, I confirm that the failure looks like $ psql -h ... -d "dbname=3Dpostgres sslmode=3Drequire" psql: error: could not connect to server: SSL error: unsupported protocol While that's not *that* awful, if you realize that "protocol" means TLS version, many people probably won't without a hint. It does not help any that the message doesn't mention either the offered TLS version or the version limits being enforced. I'm not sure we can do anything about the former, but reducing the number of variables affecting the latter seems like a smart idea. BTW, the server-side report of the problem looks like LOG: could not accept SSL connection: wrong version number regards, tom lane