TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3

Matt Caswell matt at openssl.org
Wed Apr 1 11:14:42 UTC 2020



On 01/04/2020 10:34, Romain GEISSLER via openssl-users wrote:
> Hi,
> 
> We are using OpenSSL 1.1.1 for quite some time, and we have been able to migrate over time to the different version of SSL/TLS, up to TLS 1.2 with success.
> 
> Now we wish to prepare the migration to TLS 1.3. The people used to configure our SSL connection tries to set the cipher list as they did before with TLS 1.2, with a value like: TLSv1.3:!aNULL:!eNULL
> 
> However of course it failed. We saw that starting with TLS 1.3, we shall now try to use SSL_set_ciphersuites (and its variant with _CTX) rather than SSL_set_cipher_list, and the code has been done already for that. However I would like to know a few things and get your opinion on a proposal. Currently, setting the empty string is the same as setting the default value (which is returned from OSSL_default_ciphersuites(), and which is currently more or less hardcoded to "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"). I expect that actually this default might evolve over time if we find that a given cipher is actually weak and shall not be used anymore. I also expect that one day we will have some TLS 1.4, or 2.0, or any new revision. So
> - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3" would be an alias for "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" right now, and the actual alias definition might evolve over time with new OpenSSL releases
> - Does SSL_set_ciphersuites support currently the notation "!CIPHER" to prevent a cipher from being used ?

At the moment there is a very limited set of ciphersuites that can be
configured for TLSv1.3 (5 in total) compared to TLSv1.2 (142 in total)
and below. This is partly because TLSv1.3 is new and we expect more
ciphersuites to be defined, but also partly because a TLSv1.3 is so much
simpler than a TLSv1.2 ciphersuite. A TLSv1.2 ciphersuite combines the
symmetric cipher, with the key exchange algorithm, the authentication
algorithm and the hash. In TLSv1.3 we just have the symmetric cipher and
hash. Because there are so many combinations in TLSv1.2 this multiplies
up to mean that many more ciphersuites are required.

Right now the TLSv1.3 ciphersuite list is just a simple colon separated
list of ciphersuite names. You can't do things like "!CIPHER". Given the
very much reduced set of TLSv1.3 ciphersuites it is not yet clear
whether a more expressive language to specify them is appropriate or
necessary. Perhaps this might be needed in the future but right at the
moment it looks like overkill.

Matt

> 
> My whole goal is that from configuration point of view, it looks quite like our current TLS <= 1.2 configuration, and our operator would simply configure "TLSv1.3" so that they use 1.3 explicitly, and later we will tell them to use "TLSv1.4" the day that specification exists and is implemented.
> 
> What do you think ?
> 
> PS: my knowledge about OpenSSL and the actual difference between 1.2 and 1.3 which mandated this change of API (cipher_list vs ciphersuite) is very weak. So sorry if my question looks wrong. I just see that from a user point of view without knowing the details, its a bit different to configure now, and I wish it would be as easy as "TLSv1.3".
> 
> Cheers,
> Romain
> 


More information about the openssl-users mailing list