Horton

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

Jacob Champion <jacob.champion@enterprisedb.com>

View thread View on postgr.es
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Daniel Gustafsson <daniel@yesql.se>, Erica Zhang <ericazhangy2021@qq.com>, Andres Freund <andres@anarazel.de>, Jelte Fennema-Nio <postgres@jeltef.nl>, jkatz@postgresql.org, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-11T17:37:32Z
Lists: pgsql-hackers 
On Wed, Dec 11, 2024 at 9:11 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> Sorry for chiming in so late here, but I was a little surprised to see the
> TLS version in the GUC name.  ISTM this would require us to create a new
> GUC for every new TLS version, or explain that ssl_tls13_ciphers isn't just
> for 1.3.

I agree it's not ideal. But part of the problem IMO is that we might
actually _have_ to introduce a new GUC for a future TLS 1.4, because
we have no idea if the ciphersuites will change incompatibly again. (I
hope not, but they did it once and they could do it again.)

If 1.4, or 2.0, or... 4? [1] comes out later, and it turns out to be
compatible, we could probably add a more appropriate alias then. (For
now, just as some additional data points, both Apache and Curl use
"1.3" or "13" in the configuration as a differentiator.) Do you have a
different naming scheme in mind?

--Jacob

[1] https://mailarchive.ietf.org/arch/msg/tls/KmLJ2pk0c-s3MN7ojCrXy31SjmI/

Commits

  1. Handle alphanumeric characters in matching GUC names

  2. Only perform pg_strong_random init when required