Hi Jordan,
On 5/25/23 20:03, Jordan Brown wrote:
ping?
On 5/23/2023 12:00 PM, Jordan Brown wrote:
Our application has a user interface that shows you all of the
available ciphers, and lets you select and deselect individual
ciphers. (It does *not* allow for pattern matching.)
We're working on supporting TLS 1.3. In OpenSSL, that introduces new
functions SSL_set_ciphersuites() and SSL_CTX_set_ciphersuites().
We're trying to understand how that relates to the previous functions
SSL_set_cipher_list() and SSL_CTX_set_cipher_list(). It would be
*nice* to be able to treat all cipher selection for all versions the same.
Experimentally, based on the behavior of "openssl ciphers" and its
-ciphersuites, it appears that the new function accepts all cipher
names, as long as you use the IANA TLS_* form of the name. Source
inspection suggests that -ciphersuites is implemented directly atop
SSL_CTX_set_ciphersuites().
It *appears* that the behavior is that the explicit list of IANA-named
ciphers supplied with the "set_ciphersuites" functions is unioned with
the pattern-matched list of older ciphers supplied through the old
functions.
Consider that I appear to be able to select an old cipher using the
new option (and thus the new function):
$ openssl ciphers -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA \!ALL
AES256-SHA
Is this an intended feature?
It is at least a badly implemented one. A test with 1.1.1t (for certain
reasons I can't upgrade yet), not setting a cipher suite yields with
sslscan:
Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519
DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519
DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519
DHE 253
Restricting it to the AES variants yields as expected:
Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519
DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519
DHE 253
However, submitting TLS_RSA_WITH_AES_256_CBC_SHA does not result in an
error (return value of SSL_CTX_set_ciphersuites is 1), but sslscan can't
perform a handshake. Since we limit to TLS 1.3 even before setting the
ciphersuites, using SSL_CTX_set_min_proto_version (sslctx,
TLS1_3_VERSION), this is mildly disturbing, and you are right, the
function that is supposed to set TLS 1.3 cipher suites (only) permits
older cipher suites to be set without error, breaking TLS 1.3 in the
process.
Submitting completely invalid data errors out with "no cipher match" as
expected.
Now, arguably, the caller should be aware of what they are doing, but I
would consider this worthy of an issue.
Would you raise a bug on github?
Best regards,
Christian
--
Jordan Brown, Oracle
--
Jordan Brown, Oracle
