Relationship between TLS 1.3 ciphers and earlier ciphers

[Viktor Dukhovni]

On Tue, May 23, 2023 at 07:00:13PM +0000, Jordan Brown wrote:

> 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.

There are good reasons why that would work poorly.  The choice to not
mix oil and water is well motivated.

> 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.

As expected.

> 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?

This is an unintentional artefact of the implementation.  The intent is
to only match TLS 1.3 ciphersuites.  Note that adding a TLS 1.2 cipher
to the TLS 1.3 ciphersuite list does not make it usable.  Connections
that negotiate TLS 1.3 fail when this is done.  But TLS 1.2 connections
succeed with that cipher even when all ciphers are removed from the
TLS 1.2 and prior cipher list.  Compare:

    $ openssl s_client -tls1_3 -connect '...' -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA -cipher '!ALL'
    $ openssl s_client -tls1_2 -connect '...' -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA -cipher '!ALL'

You could open an issue.  This is more of a nit than a bug, but perhaps
worth "fixing" nevertheless.

-- 
    Viktor.