Welcome! Log In Create A New Profile

Advanced

TLS 1.3 options available with OpenSSL 1.1.1

Posted by Dirkjan Bussink 
Dirkjan Bussink
TLS 1.3 options available with OpenSSL 1.1.1
September 13, 2018 03:40PM
Hi all,

With the release of OpenSSL 1.1.1, TLS 1.3 is now also available. It already is working fine in my testing with HAProxy 1.8, there is however one issue. Currently there is no way to control the ciphers for TLS 1.3 from HAProxy, as according to the OpenSSL documentation, ciphers are handled by a separate method for TLS 1.3 compared to TLS 1.2 and earlier:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html

SSL_CTX_set_cipher_list() sets the list of available ciphers (TLSv1.2 and below) for ctx using the control string str.

SSL_CTX_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites for ctx.


Before I jump into writing code for this, I’m wondering what the approach is that HAProxy wants to take here. Should a similar options as todays `ciphers` option be made available in HAProxy to control the TLS 1.3 ciphers? If so, what should that be named?

Or is another approach preferred here? For example by still using the `ciphers` configuration setting, but by then filtering out ciphers that start with `TLS13` and set those separate with `SSL_CTX_set_ciphersuites`?

Cheers,

Dirkjan Bussink
Lukas Tribus
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 13, 2018 04:20PM
Hi Dirkjan,



On Thu, 13 Sep 2018 at 15:35, Dirkjan Bussink <[email protected]> wrote:
>
> Hi all,
>
> With the release of OpenSSL 1.1.1, TLS 1.3 is now also available. It already is working fine in my testing with HAProxy 1.8, there is however one issue. Currently there is no way to control the ciphers for TLS 1.3 from HAProxy, as according to the OpenSSL documentation, ciphers are handled by a separate method for TLS 1.3 compared to TLS 1.2 and earlier:
>
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html
>
> SSL_CTX_set_cipher_list() sets the list of available ciphers (TLSv1.2 and below) for ctx using the control string str.
>
> SSL_CTX_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites for ctx.
>
>
> Before I jump into writing code for this, I’m wondering what the approach is that HAProxy wants to take here. Should a similar options as todays `ciphers` option be made available in HAProxy to control the TLS 1.3 ciphers? If so, what should that be named?
>
> Or is another approach preferred here? For example by still using the `ciphers` configuration setting, but by then filtering out ciphers that start with `TLS13` and set those separate with `SSL_CTX_set_ciphersuites`?

Definitely not some by string matching, openssl could have done
exactly that, they choose to make a new API call instead, and they
expect applications to introduce new configuration knobs or use the
generic configuration interface SSL_CONF, so no, let's not get crazy
with string magic here and expose the API as-is to the users
(SSL_CTX_set_ciphersuites() or the generic SSL_CONF().

I assume we don't have to change anything regarding groups/curves,
although they implemented the new SSL_CTX_set1_groups() call, but if I
understand correctly SSL_CTX_set1_curves_list() works just as well
with TLSv1.3, right?



Thanks,
Lukas
Dirkjan Bussink
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 13, 2018 04:50PM
Hi Lukas,

> On 13 Sep 2018, at 16:14, Lukas Tribus <[email protected]> wrote:
>
> Definitely not some by string matching, openssl could have done
> exactly that, they choose to make a new API call instead, and they
> expect applications to introduce new configuration knobs or use the
> generic configuration interface SSL_CONF, so no, let's not get crazy
> with string magic here and expose the API as-is to the users
> (SSL_CTX_set_ciphersuites() or the generic SSL_CONF().


So with a new API call, does that mean adding for example a `ciphersuites` option that works similar to `ciphers` today that it accepts a string and then calls `SSL_CTX_set_ciphersuites`? I can see if I can create a patch that does that (and ideally would be possible to backport to 1.8 as well, since I would like to be able to run TLS 1.3 then with 1.8 which works perfectly fine apart from a lack of tuning for this).

> I assume we don't have to change anything regarding groups/curves,
> although they implemented the new SSL_CTX_set1_groups() call, but if I
> understand correctly SSL_CTX_set1_curves_list() works just as well
> with TLSv1.3, right?

Yes, these work with TLSv1.3 still, but according to https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_curves_list.html there is preference for the groups functions (but not something I think needs to be addressed in the same patch / change?):

---

The curve functions are synonyms for the equivalently named group functions and are identical in every respect. They exist because, prior to TLS1.3, there was only the concept of supported curves. In TLS1.3 this was renamed to supported groups, and extended to include Diffie Hellman groups. The group functions should be used in preference.

---


Cheers,

Dirkjan
Lukas Tribus
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 13, 2018 10:30PM
Hello Dirkjan,


On Thu, 13 Sep 2018 at 16:44, Dirkjan Bussink <[email protected]> wrote:
> So with a new API call, does that mean adding for example a `ciphersuites`
> option that works similar to `ciphers` today that it accepts a string and then
> calls `SSL_CTX_set_ciphersuites`?

Yes, that's what I'd have in mind. Sufficiently #ifdef that everything
still builds the same and documented of course so that people
understand what is what. Let's wait for Manu and Emeric's feedback
though, before investing your time.


> The curve functions are synonyms for the equivalently named group functions
> and are identical in every respect.

So there is no technical reason to implement the new API call, it's
just to go with the new naming convention. No need for any action
then, we don't have to blow up our code with additional #ifdef mess
for the sake of using better looking names in API calls.


Thanks for looking into this!

cheers,
lukas
Emeric Brun
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 14, 2018 11:20AM
Hi Lukas, Dirkjan,

On 09/13/2018 10:17 PM, Lukas Tribus wrote:
> Hello Dirkjan,
>
>
> On Thu, 13 Sep 2018 at 16:44, Dirkjan Bussink <[email protected]> wrote:
>> So with a new API call, does that mean adding for example a `ciphersuites`
>> option that works similar to `ciphers` today that it accepts a string and then
>> calls `SSL_CTX_set_ciphersuites`?
>
> Yes, that's what I'd have in mind. Sufficiently #ifdef that everything
> still builds the same and documented of course so that people
> understand what is what. Let's wait for Manu and Emeric's feedback
> though, before investing your time.

I think if TLSv <= 1.2 and TLSv1.3 ciphers are handled separately, this is good reason
to add a new keyword to manage both at a same line on an haproxy configuration file's line .

I've just realized that it may be the openssl's response to an issue we faced on earlier version of
openssl1.1.1 dev branch where forcing cipher suite on a SSL_CTX broke TLSv1.2 handshakes if
no TLSv1.3 ciphers were specified in this list.

Doing this, managing differently TLS <= v1.2 and 1.3 ciphers permits the user to not face regression issues
upgrading to v1.1.1 when suites where forced in configuration because openssl-1.1.1 kept default
TVSv1.3 ciphers.

So i'm convinced we need to handle this new TLSv1.3 cipher suite with a new config keyword, but I
don't know how we should name it. I think it will be a mistake to make appear 1.3 in the new name because
there is no warranty that next TLS versions will specify specific cipher lists. Openssl's
API make the choice of "ciphersuites" ... perhaps a the right choice.

Did any of you check how this is endled on "openssl s_client" command line?

>
>
>> The curve functions are synonyms for the equivalently named group functions
>> and are identical in every respect.
>
> So there is no technical reason to implement the new API call, it's
> just to go with the new naming convention. No need for any action
> then, we don't have to blow up our code with additional #ifdef mess
> for the sake of using better looking names in API calls.

Perfectly agreed.

>
> Thanks for looking into this!
>
> cheers,
> lukas
>
R,
Emeric
Dirkjan Bussink
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 14, 2018 12:20PM
Hi all,

I took the liberty of writing up a patch with what this could look like. I have named the option `ciphersuites` and also added the documentation for it as well. I have attached the patch to this email.


> On 14 Sep 2018, at 11:12, Emeric Brun <[email protected]> wrote:
>
> I think if TLSv <= 1.2 and TLSv1.3 ciphers are handled separately, this is good reason
> to add a new keyword to manage both at a same line on an haproxy configuration file's line .

This is what my patch does indeed.

> I've just realized that it may be the openssl's response to an issue we faced on earlier version of
> openssl1.1.1 dev branch where forcing cipher suite on a SSL_CTX broke TLSv1.2 handshakes if
> no TLSv1.3 ciphers were specified in this list.
>
> Doing this, managing differently TLS <= v1.2 and 1.3 ciphers permits the user to not face regression issues
> upgrading to v1.1.1 when suites where forced in configuration because openssl-1.1.1 kept default
> TVSv1.3 ciphers.

Yeah, without the configurations setting it uses the 1.3 defaults which are already good safe defaults.

> So i'm convinced we need to handle this new TLSv1.3 cipher suite with a new config keyword, but I
> don't know how we should name it. I think it will be a mistake to make appear 1.3 in the new name because
> there is no warranty that next TLS versions will specify specific cipher lists. Openssl's
> API make the choice of "ciphersuites" ... perhaps a the right choice.

That’s what I did :). Hopefully it looks somewhat sensible.

> Did any of you check how this is endled on "openssl s_client" command line?

From the help for this command:

-cipher val Specify TLSv1.2 and below cipher list to be used
-ciphersuites val Specify TLSv1.3 ciphersuites to be used

So it does the same thing as my patch does.

Cheers,

Dirkjan
Attachments:
open | download - 0001-Add-support-for-ciphersuites-option-for-TLS-1.3.patch (19.1 KB)
Emmanuel Hocdet
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 14, 2018 12:30PM
Hi Emeric, Lukas, Dirkjan

> Le 14 sept. 2018 à 11:12, Emeric Brun <[email protected]> a écrit :
>
> Hi Lukas, Dirkjan,
>
> On 09/13/2018 10:17 PM, Lukas Tribus wrote:
>> Hello Dirkjan,
>>
>>
>> On Thu, 13 Sep 2018 at 16:44, Dirkjan Bussink <[email protected]> wrote:
>>> So with a new API call, does that mean adding for example a `ciphersuites`
>>> option that works similar to `ciphers` today that it accepts a string and then
>>> calls `SSL_CTX_set_ciphersuites`?
>>
>> Yes, that's what I'd have in mind. Sufficiently #ifdef that everything
>> still builds the same and documented of course so that people
>> understand what is what. Let's wait for Manu and Emeric's feedback
>> though, before investing your time.
>
> I think if TLSv <= 1.2 and TLSv1.3 ciphers are handled separately, this is good reason
> to add a new keyword to manage both at a same line on an haproxy configuration file's line .
>
> I've just realized that it may be the openssl's response to an issue we faced on earlier version of
> openssl1.1.1 dev branch where forcing cipher suite on a SSL_CTX broke TLSv1.2 handshakes if
> no TLSv1.3 ciphers were specified in this list.
>
> Doing this, managing differently TLS <= v1.2 and 1.3 ciphers permits the user to not face regression issues
> upgrading to v1.1.1 when suites where forced in configuration because openssl-1.1.1 kept default
> TVSv1.3 ciphers.
>

Same deal with boringssl, TLSv <= 1.2 ciphers configuration and TLSv1.3 ciphers are segregated.
https://boringssl.googlesource.com/boringssl/+/abbbee10ad4739648bcbf36a5ac52f23263a67dd%5E!/

> So i'm convinced we need to handle this new TLSv1.3 cipher suite with a new config keyword, but I
> don't know how we should name it. I think it will be a mistake to make appear 1.3 in the new name because
> there is no warranty that next TLS versions will specify specific cipher lists. Openssl's
> API make the choice of "ciphersuites" ... perhaps a the right choice.


Following the API name should be the right choice.

++
Manu
Dirkjan Bussink
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 14, 2018 02:10PM
Hi all,

> On 14 Sep 2018, at 12:18, Emmanuel Hocdet <[email protected]> wrote:
>
> Same deal with boringssl, TLSv <= 1.2 ciphers configuration and TLSv1.3 ciphers are segregated.
> https://boringssl.googlesource.com/boringssl/+/abbbee10ad4739648bcbf36a5ac52f23263a67dd%5E!/

This reminded me to double check with BoringSSL and LibreSSL how they handle this. Neither has this new method, so I have updated the conditional used in the patch to exclude these two as well.

Cheers,

Dirkjan
Attachments:
open | download - 0001-Add-support-for-ciphersuites-option-for-TLS-1.3.patch (20.6 KB)
Emmanuel Hocdet
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 14, 2018 02:20PM
> Le 14 sept. 2018 à 14:01, Dirkjan Bussink <d.bussi[email protected]> a écrit :
>
> Hi all,
>
>> On 14 Sep 2018, at 12:18, Emmanuel Hocdet <[email protected]> wrote:
>>
>> Same deal with boringssl, TLSv <= 1.2 ciphers configuration and TLSv1.3 ciphers are segregated.
>> https://boringssl.googlesource.com/boringssl/+/abbbee10ad4739648bcbf36a5ac52f23263a67dd%5E!/
>
> This reminded me to double check with BoringSSL and LibreSSL how they handle this. Neither has this new method, so I have updated the conditional used in the patch to exclude these two as well.
>

It’s not necessary, BoringSSL and LibreSSL have, at best, OPENSSL_VERSION_NUMBER set to 1.1.0 for API compatibilité.

++
Manu
Dirkjan Bussink
Re: TLS 1.3 options available with OpenSSL 1.1.1
September 14, 2018 02:40PM
Hi all,

> On 14 Sep 2018, at 14:15, Emmanuel Hocdet <[email protected]> wrote:
>
> It’s not necessary, BoringSSL and LibreSSL have, at best, OPENSSL_VERSION_NUMBER set to 1.1.0 for API compatibilité.

Looking at LibreSSL, it’s defining this (in their latest Git code):

src/lib/libcrypto/opensslv.h:#define OPENSSL_VERSION_NUMBER 0x20000000L

I also see this conditional used in other places to explicitly exclude BoringSSL and LibreSSL, so that’s why I thought it would be needed here as well.

--
Cheers,

Dirkjan
Sorry, only registered users may post in this forum.

Click here to login