Re: Improve errors when setting incorrect bounds for SSL protocols

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improve errors when setting incorrect bounds for SSL protocols
Date: 2020-01-14 10:21:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 14 Jan 2020, at 04:54, Michael Paquier <michael(at)paquier(dot)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:
> 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-01-14 10:35:22 Re: [HACKERS] WAL logging problem in 9.4.3?
Previous Message Dean Rasheed 2020-01-14 10:18:38 Re: Errors when update a view with conditional-INSTEAD rules