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 1jpE71-0002il-3z for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Jun 2020 16:55:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jpE6z-0003FY-6Q for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Jun 2020 16:55:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpE6y-0003FF-VU for pgsql-hackers@lists.postgresql.org; Sat, 27 Jun 2020 16:55:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpE6w-0002RW-KZ for pgsql-hackers@postgresql.org; Sat, 27 Jun 2020 16:55:27 +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 05RGtL2Z142461; Sat, 27 Jun 2020 12:55:22 -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: <31488.1593206864@sss.pgh.pa.us> References: <4FBC50DB-599A-42AA-90C8-3051E3A748BB@yesql.se> <2305871.1593125045@sss.pgh.pa.us> <2339796.1593177583@sss.pgh.pa.us> <16724.1593185802@sss.pgh.pa.us> <29049.1593202957@sss.pgh.pa.us> <0817C931-564B-4DFF-921C-90915889F451@yesql.se> <31488.1593206864@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 26 Jun 2020 17:27:44 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <142459.1593276921.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Jun 2020 12:55:21 -0400 Message-ID: <142460.1593276921@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Daniel Gustafsson writes: >> SSL_R_UNKNOWN_PROTOCOL seem to covers cases when someone manages to per= form >> something which OpenSSL believes is a broken SSLv2 connection, but thei= r own >> client-level code use it to refer to SSL as well as TLS. Maybe it's wo= rth >> adding as a belts and suspenders type thing? > No objection on my part. >> If anything it might useful to document in the comment that we're only >> concerned with TLS versions, SSL2/3 are disabled in the library initial= ization. > Good point. Pushed with those corrections. I also rewrote the comment about which error codes we'd seen in practice, after realizing that one of my tests had been affected by the presence of "MinProtocol =3D TLSv1.2" in RHEL8's openssl.cnf (causing a max setting less than that to be a local configuration error, not something the server had rejected). regards, tom lane