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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
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
Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2


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
>
Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
>    - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3"

Suppose someone finds out that chacha/poly is insecure and the IETF issues a new RFC that says "TLS 1.3 MUST NOT use" that cipher.  Should the openssl alias change?

It can be wordy, but explicitly listing ciphers and not using aliases (HIGH EXPORT etc) is really better.

As for ease of use, just don't allow the ciphers to be configured.

Reply | Threaded
Open this post in threaded view
|

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

OpenSSL - User mailing list
> Le 1 avr. 2020 à 15:19, Salz, Rich <[hidden email]> a écrit :
>
>>   - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3"
>
> Suppose someone finds out that chacha/poly is insecure and the IETF issues a new RFC that says "TLS 1.3 MUST NOT use" that cipher.  Should the openssl alias change?
>
> It can be wordy, but explicitly listing ciphers and not using aliases (HIGH EXPORT etc) is really better.
>
> As for ease of use, just don't allow the ciphers to be configured.
>

Hi,

Well, as a user of openssl, in the same scenario, I would draw the exact opposite conclusion ;)

Let me elaborate. We as users don’t really know well how secure is a cipher, and we don’t really OpenSSL nor IETF discussions about these details. I am not saying they don’t matter, of course not, but as users, we are not expert of this, and we don’t follow it. However, what we do is follow regularly releases of OpenSSL: when a new stable release is out, we quickly migrate to it. As a user, I would see an added value to define aliases, because I definitely don’t want to hardcode in our config that we explicitly allow the usage of ciper X, Y or Z, as this config might "rot" over time and not follow state of the art config. However I do want to express the fact that I either allow any default ciphers (ie some kind of default config that would be based on OSSL_default_ciphersuites), or that I explicitly want to support the TLS 1.3-compliant ciphers but not the TLS 1.4 ones (if one day 1.4 is out, and for some reason, they can’t use the same set of default ciphers). This way we users express high level needs (ie famillies of ciphers), and you OpenSSL developer ensure the details of it, and make the alias content evolve over time if one day a cipher is found to be weak. So yes to answer your question, the openssl alias name should stay the same, but its actual meaning (ie ciper suite list) should evolve over time.

This is one opinion, from user perspective. At least this is the vision we were used to with cipher lists for TLS <= 1.2, in which we definitely didn’t want to explicitly hardcode a list of ciphers about which we honestly have no idea of their cryptographic security, alias "TLSv1.2" was convenient.

Cheers,
Romain
Reply | Threaded
Open this post in threaded view
|

TLS 1.3 migration: how to get current SSL session authentication

Michel
In reply to this post by Matt Caswell-2
Hi,

By the way :
It was possible to get the authentication from a TLS1.2 ciphersuite
Using SSL_CIPHER_get_auth_nid().

With a TLS1.3 SSL_CIPHER, the result is logically 'any'.

So my question is :
Is there any other [new ?] API to get the effective authentication mode
from the current SSL session (RSA, PSK, ...) ?
Or do we need to rely on a [/PSK like] callback ?

Regards,

Michel.

-----Message d'origine-----
[...]
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.
[...]