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