Re: Add support to TLS 1.3 cipher suites and curves lists - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Add support to TLS 1.3 cipher suites and curves lists
Date
Msg-id CAOYmi+mV7bK+oWEbCjGFipeb8ZFd98bxLiTkVO0Tm4DT-HS09Q@mail.gmail.com
Whole thread Raw
In response to Re:Re: Add support to TLS 1.3 cipher suites and curves lists  ("Erica Zhang" <ericazhangy2021@qq.com>)
Responses Re: Add support to TLS 1.3 cipher suites and curves lists
List pgsql-hackers
On Wed, Sep 25, 2024 at 6:39 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> I can't recall specific bounds for supporting LibreSSL even being discussed,
> the support is also not documented as an official thing.  Requiring TLS 1.3
> APIs for supporting a library in 2025 (when 18 ships) doesn't seem entirely
> unreasonable so maybe 3.4 is a good cutoff.  The fact that LibreSSL trailed
> behind OpenSSL in adding these APIs shouldn't limit our functionality.

Okay. At minimum I think we'll lose conchuela, plover, and morepork
from the master builds until they are updated. schnauzer is new enough
to keep going.

> Thinking on it a bit I went (to some
> degree inspired by what we did in curl) with ssl_tls13_ciphers which makes the
> name very similar to the tls12 GUC but with the clear distinction of being
> protocol specific.  It also makes the GUC name more readable to place the
> protocol before "ciphers" I think.

Looks fine to me.

> I ended
> up adding a version of SSLerrmessage which takes a replacement string for ecode
> 0 (which admittedly is hardcoded version knowledge as well..).  This can be
> used for scenarios when it's known that OpenSSL sometimes reports and error and
> sometimes not (I'm sure there are quite a few more).

I like this new API! And yeah, I think it'll get more use elsewhere.

My only nitpick for this particular error message is that there's no
longer any breadcrumb back to the setting that's broken:

    FATAL:  ECDH: failed to set curve names: No valid groups found
    HINT:  Ensure that each group name is spelled correctly and
supported by the installed version of OpenSSL

If I migrate a server to a different machine that doesn't support my
groups, I don't know that this would give me enough information to fix
the configuration.

--

One nice side effect of the new ssl_groups implementation is that we
now support common group aliases. For example, "P-256", "prime256v1",
and "secp256r1" can all be specified now, whereas before ony
"prime256v1" worked because of how we looked up curves. Is that worth
a note in the docs? Even if not, it might be good to keep in mind for
support threads.

Thanks,
--Jacob



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Rename PageData to XLogPageData
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_parse_json() should not leak token copies on failure