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

From Jonathan S. Katz
Subject Re: Add support to TLS 1.3 cipher suites and curves lists
Date
Msg-id d56a18d1-e37e-40a1-8c96-5daa280c593d@postgresql.org
Whole thread Raw
In response to Re: Add support to TLS 1.3 cipher suites and curves lists  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On 12/11/24 10:14 AM, Daniel Gustafsson wrote:
>> On 11 Dec 2024, at 18:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
>> Oh yay, another naming problem :-(.  I think that neither "ciphers"
>> vs. "cipher suites" nor "ssl_ciphers" vs. "ssl_ciphers_tlsv13" is
>> going to convey a lot to the average person who's not steeped in
>> TLS minutiae.  However, following the precedent of Apache and Curl
>> seems like a good answer --- that will ensure that at least some
>> part of the internet-using world has seen this before.  So I guess
>> I'm +0.5 for the ssl_ciphers_tlsv13 answer, at least out of the
>> choices suggested so far.
> 
> The subset of users who are likely to be interested in this setting would
> probably be more confused if we didn't follow the precedent from other
> well-known projects.

+1 to this point. The people I talk to who are interested in the 
`cipher_suites` setting, are also the folks who are actually paying 
attention to when and how ciphers/ciphersuites are used, and have strong 
opinions on such. It also seems that OpenSSL is pushing in the direction 
of making everything a "ciphersuite", albeit the -ciphersuites flag is 
just for TLS v1.3+[1].

I think the `ssl_cipher_suites` proposal is fine; OK with bikeshedding 
to `ssl_ciphersuites`.

Thanks,

Jonathan

[1] https://docs.openssl.org/3.3/man1/openssl-ciphers/#options



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_createsubscriber TAP test wrapping makes command options hard to read.
Next
From: jian he
Date:
Subject: Re: Pass ParseState as down to utility functions.