Re: Add support to TLS 1.3 cipher suites and curves lists

> On 2 Oct 2024, at 19:16, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Wed, Sep 25, 2024 at 6:39 AM Daniel Gustafsson <daniel(at)yesql(dot)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.

I will raise it on the thread where bumping to 1.1.1 as the lowest supported
version to make sure it doesn't land as a surprise.

> 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.

Fair point, how about something along the lines of:

+ errmsg("ECDH: failed to set curve names specified in ssl_groups: %s",
+ SSLerrmessageExt(ERR_get_error(),
+ _("No valid groups found"))),

> 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?

Maybe. We have this currently in the manual:

"The full list of available curves can be shown with the command
<command>openssl ecparam -list_curves</command>. Not all of them are
usable with <acronym>TLS</acronym> though."

Perhaps we can extend that with a short not on aliases? Got any suggested
wordings for that if so?

--
Daniel Gustafsson