> On 14 Jan 2020, at 04:54, Michael Paquier <mich...@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-cb7943a27...@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
