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

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 24 Jun 2020, at 10:46, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> It might also be worth noting that it's not really "any protocol version", it means it will be "whatever the openssl configuration says", I think? For example, debian buster sets:
>>
>> [system_default_sect]
>> MinProtocol = TLSv1.2
>>
>> Which I believe means that if your libpq app is running on debian buster, 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 enforce 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=tlsv1". After
some digging I verified that that's because RHEL8's openssl.cnf sets

MinProtocol = TLSv1.2
MaxProtocol = TLSv1.3

Interestingly, Fedora 32 is laxer:

MinProtocol = TLSv1
MaxProtocol = 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=postgres sslmode=require"
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