> On 14 Jan 2020, at 04:54, Michael Paquier <michael@paquier.xyz> wrote:
>
> Hi all,
> (Daniel G. in CC.)
>
> 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:
> https://www.postgresql.org/message-id/9CFA34EE-F670-419D-B92C-CB7943A27573@yesql.se
>
> 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
>
> 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
