Relationship between TLS 1.3 ciphers and earlier ciphers

[Christian Schmidt]

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
>