Re: Improve errors when setting incorrect bounds for SSL protocols

> On 14 Jan 2020, at 04:54, Michael Paquier <[email protected]> wrote:
>=20
> Hi all,
> (Daniel G. in CC.)
>=20
> As discussed on the thread to be able to set the min/max SSL protocols
> with libpq, when mixing incorrect bounds the user experience is not
> that good:=20
> =
https://www.postgresql.org/message-id/9CFA34EE-F670-419D-B92C-CB7943A27573=
@yesql.se
>=20
> It happens that the error generated with incorrect combinations
> depends solely on what OpenSSL thinks is fine, and that's the
> following:
> psql: error: could not connect to server: SSL error: tlsv1 alert
> internal error
>=20
> It is hard for users to understand what such an error means and how to
> act on it.

Correct, it's an easy mistake to make but based on the error it might =
take some
time to figure it out.

> Please note that OpenSSL 1.1.0 has added two routines to be able to
> get the min/max protocols set in a context, called
> SSL_CTX_get_min/max_proto_version.  Thinking about older versions of
> OpenSSL I think that it is better to use
> ssl_protocol_version_to_openssl to do the parsing work.  I also found
> that it is easier to check for compatible versions after setting both
> bounds in the SSL context, so as there is no need to worry about
> invalid values depending on the build of OpenSSL used.

I'm not convinced that it's a good idea to check for incompatible =
protocol
range in the OpenSSL backend.  We've spent a lot of energy to make the =
TLS code
library agnostic and pluggable, and since identifying a basic =
configuration
error isn't OpenSSL specific I think it should be in the guc code.  That =
would
keep the layering as well as ensure that we don't mistakenly treat this
differently should we get a second TLS backend.

cheers ./daniel=