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

Hi All,
Frist of all really appreciate the review of my patch. I've seperated the patch into two: patch_support_tls1.3 for tls1.3 support and patch_support_curves_group for a set of curves list.

TLS1.3 support - patch_support_tls1.3
I agree with Jelte that it's better to have different options for tls1.2 and lower(cipher list) and tls1.3(cipher suite) since openssl provided different APIs for each. As for users not faimilar with TLS（they don't care TLS,）we can still keep the default value as described here https://www.postgresql.org/docs/devel/runtime-config-connection.html. If TLS is critical to them(they should have figured out the different options in tls1.2 and tls1.3), then they can set the values on-demand. Moreover we can add some description of these two options.

eg. 
ssl_ciphers                                 | HIGH:MEDIUM:+3DES:!aNULL                      | Sets the list of allowed SSL ciphers for TLS1.2 and lower.             
ssl_ciphers_suites                          | HIGH:MEDIUM:+3DES:!aNULL                 | Sets the list of allowed SSL cipher suites for TLS1.3.

Curves groups - patch_support_curves_group
Indeed SSL_CTX_set1_curves_list is deprecated it's bette to change to SSL_CTX_set1_groups_list instead.

Original Email

Sender:"Jelte Fennema-Nio"< postgres(at)jeltef(dot)nl &gt;;

Sent Time:2024/6/12 16:51

To:"Daniel Gustafsson"< daniel(at)yesql(dot)se &gt;;

Cc recipient:"Erica Zhang"< ericazhangy2021(at)qq(dot)com &gt;;"Jacob Champion"< jacob(dot)champion(at)enterprisedb(dot)com &gt;;"Peter Eisentraut"< peter(at)eisentraut(dot)org &gt;;"pgsql-hackers"< pgsql-hackers(at)lists(dot)postgresql(dot)org &gt;;

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

On Mon, 10 Jun 2024 at 12:31, Daniel Gustafsson wrote:
&gt; Regarding the ciphersuites portion of the patch. I'm not particularly thrilled
&gt; about having a GUC for TLSv1.2 ciphers and one for TLSv1.3 ciphersuites, users
&gt; not all that familiar with TLS will likely find it confusing to figure out what
&gt; to do.

I don't think it's easy to create a single GUC because OpenSSL has
different APIs for both. So we'd have to add some custom parsing for
the combined string, which is likely to cause some problems imho. I
think separating them is the best option from the options we have and
I don't think it matters much practice for users. Users not familiar
with TLS might indeed be confused, but those users shouldn't touch
these settings anyway, and just use the defaults. The users that care
about this probably already get two cipher strings from their
compliance teams, because many other applications also have two
separate options for specifying both.

Hi,

This thread was referenced by https://www.postgresql.org/message-id/48F0A1F8-E0B4-41F8-990F-41E6BA2A6185%40yesql.se

On 2024-06-13 14:34:27 +0800, Erica Zhang wrote:

> diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
> index 39b1a66236..d097e81407 100644
> --- a/src/backend/libpq/be-secure-openssl.c
> +++ b/src/backend/libpq/be-secure-openssl.c
> @@ -1402,30 +1402,30 @@ static bool
> initialize_ecdh(SSL_CTX *context, bool isServerStart)
> {
> #ifndef OPENSSL_NO_ECDH
> - EC_KEY *ecdh;
> - int nid;
> + char *curve_list = strdup(SSLECDHCurve);

ISTM we'd want to eventually rename the GUC variable to indicate it's a list?
I think the "ecdh" portion is actually not accurate anymore either, it's used
outside of ecdh if I understand correctly (probably I am not)?

> + char *saveptr;
> + char *token = strtok_r(curve_list, ":", &saveptr);
> + int nid;
>
> - nid = OBJ_sn2nid(SSLECDHCurve);
> - if (!nid)
> + while (token != NULL)

It'd be good to have a comment explaining why we're parsing the list ourselves
instead of using just the builtin SSL_CTX_set1_groups_list().

> {
> - ereport(isServerStart ? FATAL : LOG,
> + nid = OBJ_sn2nid(token);
> + if (!nid)
> + {ereport(isServerStart ? FATAL : LOG,
> (errcode(ERRCODE_CONFIG_FILE_ERROR),
> - errmsg("ECDH: unrecognized curve name: %s", SSLECDHCurve)));
> + errmsg("ECDH: unrecognized curve name: %s", token)));
> return false;
> + }
> + token = strtok_r(NULL, ":", &saveptr);
> }
>
> - ecdh = EC_KEY_new_by_curve_name(nid);
> - if (!ecdh)
> + if(SSL_CTX_set1_groups_list(context, SSLECDHCurve) !=1)
> {
> ereport(isServerStart ? FATAL : LOG,
> (errcode(ERRCODE_CONFIG_FILE_ERROR),
> - errmsg("ECDH: could not create key")));
> + errmsg("ECDH: failed to set curve names")));

Probably worth including the value of the GUC here?

This also needs to change the documentation for the GUC.

Once we have this parameter we probably should add at least x25519 to the
allowed list, as that's the client side default these days.

But that can be done in a separate patch.

Greetings,

Andres Freund