Re: Setting min/max TLS protocol in clientside libpq - Mailing list pgsql-hackers

From cary huang
Subject Re: Setting min/max TLS protocol in clientside libpq
Date
Msg-id 157800160408.1198.1714906047977693148.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Re: Setting min/max TLS protocol in clientside libpq  (Arthur Zakirov <zaartur@gmail.com>)
Responses Re: Setting min/max TLS protocol in clientside libpq
List pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            tested, passed

Hello

I have applied the patch and did some basic testing with various combination of min and max TLS protocol versions.
Overallthe functionality works and the chosen TLS protocol aligns with the min/max TLS protocol settings on the PG
serverside.
 

I agree with Arthur that it makes sense to check the validity of "conn->sslmaxprotocolversion" first before checking if
itis larger than "conn->sslminprotocolversion"
 

A small suggestion here. I see that PG server defaults TLS min version to be TLSv1.2 and max version to none. So by
defaultthe server accepts TLSv1.2 and above. I think on the client side, it also makes sense to have the same defaults
asthe server. In the patch, if the client does not supply "sslminprotocolversion", it will run to "else" statement and
setsTLS min version to "INT_MIN", which is a huge negative number and of course openssl won't set it. I think this else
statementcan be enhanced a little to set "sslminprotocolversion" to TLSv1.2 by default to match the server and provide
somewarning message that TLS minimum has defaulted to TLSv1.2.
 

Cary
HighGo Software Canada

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: _bt_delitems_delete() should use XLogRegisterBufData(), not XLogRegisterData()
Next
From: Tomas Vondra
Date:
Subject: Re: Commit fest manager for 2020-01