Welcome! Log In Create A New Profile

Advanced

Some compilation SSL errors/warnings on debian testing

Posted by Pavlos Parissis 
Pavlos Parissis
Some compilation SSL errors/warnings on debian testing
March 14, 2017 04:50PM
Hi,

On Debian testing with openssl 1.1.0e, I get the following warnings when I
compile 1.7 and 1.8:
https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt

When I compile 1.6 I get errors and compilation fails:
https://gist.githubusercontent.com/unixsurfer/4476410bbbaf2192af591123f4388850/raw/a733808a3028f0c9d7f53f4e699da6de3ae18969/gistfile1.txt

I compile it with:
make clean;make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
USE_PCRE_JIT=1 USE_TPROXY=1

Am I the only seeing these warnings/errors? Searched on ML and someone mentioned
that haproxy 1.6 wont support 1.1.0 version of openssl, is this accurate? Having
openssl 1.0.2 and 1.1.0 on my personal development machine is fine, so zero
problems here if 1.6 does not support openssl 1.1.0 version.

Cheers,
Pavlos
Willy Tarreau
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 05:30PM
Hi Pavlos,

On Tue, Mar 14, 2017 at 04:43:26PM +0100, Pavlos Parissis wrote:
> Hi,
>
> On Debian testing with openssl 1.1.0e, I get the following warnings when I
> compile 1.7 and 1.8:
> https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt

Yes these ones are known and for now we don't have any workaround. It
seems openssl 1.1 wants us to drop support for older TLS versions, but
we definitely can't do that so we'll have to live with the warnings :-/
I couldn't find a way to make them disappear.

> When I compile 1.6 I get errors and compilation fails:
> https://gist.githubusercontent.com/unixsurfer/4476410bbbaf2192af591123f4388850/raw/a733808a3028f0c9d7f53f4e699da6de3ae18969/gistfile1.txt

This is indeed expected, openssl 1.1's API is very different from 1.0.

> I compile it with:
> make clean;make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
> USE_PCRE_JIT=1 USE_TPROXY=1
>
> Am I the only seeing these warnings/errors? Searched on ML and someone mentioned
> that haproxy 1.6 wont support 1.1.0 version of openssl, is this accurate? Having
> openssl 1.0.2 and 1.1.0 on my personal development machine is fine, so zero
> problems here if 1.6 does not support openssl 1.1.0 version.

Yes that's accurate. The risk of breakage is far too high for this to be
backported to 1.6. With 1.7 not much different from 1.6, we'll have all
people willing to explore openssl 1.1 users upgrade to haproxy 1.7 with
very limited risks (and BTW some of the bugs currently affecting 1.7 are
also on 1.6 and are in fact uncovered by some fixes for bugs that were
hiding other ones).

Hoping this helps!

Cheers,
Willy
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 05:50PM
Hi Pavlos

> Le 14 mars 2017 à 16:43, Pavlos Parissis <[email protected]> a écrit :
>
> Hi,
>
> On Debian testing with openssl 1.1.0e, I get the following warnings when I
> compile 1.7 and 1.8:
> https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt
>
> When I compile 1.6 I get errors and compilation fails:
> https://gist.githubusercontent.com/unixsurfer/4476410bbbaf2192af591123f4388850/raw/a733808a3028f0c9d7f53f4e699da6de3ae18969/gistfile1.txt
>
> I compile it with:
> make clean;make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
> USE_PCRE_JIT=1 USE_TPROXY=1
>
> Am I the only seeing these warnings/errors? Searched on ML and someone mentioned
> that haproxy 1.6 wont support 1.1.0 version of openssl, is this accurate? Having
> openssl 1.0.2 and 1.1.0 on my personal development machine is fine, so zero
> problems here if 1.6 does not support openssl 1.1.0 version.
>
> Cheers,
> Pavlos
>


For the little story: openssl-1.1.0 and boringssl have SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version
and other methods to set protocol version are deprecated (or not implemented).
It will be boring to keep compat with haproxy ssl directive no-<method> and force-<method>.
And perhaps the add of some min-<method> and max-<method>.

Willy, what do you think?

Manu
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 07:00PM
Hi Willy,

> Le 14 mars 2017 à 17:24, Willy Tarreau <[email protected]> a écrit :
>
> Hi Pavlos,
>
> On Tue, Mar 14, 2017 at 04:43:26PM +0100, Pavlos Parissis wrote:
>> Hi,
>>
>> On Debian testing with openssl 1.1.0e, I get the following warnings when I
>> compile 1.7 and 1.8:
>> https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt
>
> Yes these ones are known and for now we don't have any workaround. It
> seems openssl 1.1 wants us to drop support for older TLS versions, but
> we definitely can't do that so we'll have to live with the warnings :-/
> I couldn't find a way to make them disappear.
>

Mails crossed.
I have an idea how to deal with that. I will try to propose a patch.

Manu
Willy Tarreau
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 07:20PM
Hi Manu,

[ccing Emeric]

On Tue, Mar 14, 2017 at 05:39:58PM +0100, Emmanuel Hocdet wrote:
> Hi Pavlos
>
> > Le 14 mars 2017 à 16:43, Pavlos Parissis <[email protected]> a écrit :
> >
> > Hi,
> >
> > On Debian testing with openssl 1.1.0e, I get the following warnings when I
> > compile 1.7 and 1.8:
> > https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt
> >
> > When I compile 1.6 I get errors and compilation fails:
> > https://gist.githubusercontent.com/unixsurfer/4476410bbbaf2192af591123f4388850/raw/a733808a3028f0c9d7f53f4e699da6de3ae18969/gistfile1.txt
> >
> > I compile it with:
> > make clean;make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
> > USE_PCRE_JIT=1 USE_TPROXY=1
> >
> > Am I the only seeing these warnings/errors? Searched on ML and someone mentioned
> > that haproxy 1.6 wont support 1.1.0 version of openssl, is this accurate? Having
> > openssl 1.0.2 and 1.1.0 on my personal development machine is fine, so zero
> > problems here if 1.6 does not support openssl 1.1.0 version.
> >
> > Cheers,
> > Pavlos
> >
>
>
> For the little story: openssl-1.1.0 and boringssl have SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version
> and other methods to set protocol version are deprecated (or not implemented).
> It will be boring to keep compat with haproxy ssl directive no-<method> and force-<method>.
> And perhaps the add of some min-<method> and max-<method>.
>
> Willy, what do you think?

Well, that means we'll definitely break all setups and piss-off users :-(

What we can possibly do is to determine the appropriate min/max based on
the existing no-<foo> and force-<foo> and complain if there are holes.
Ie, if a user has "no-sslv3 no-tls10 no-tls11" then the min version is
TLS 1.2 and that could work. If a user has "no-sslv3 no-tls11 no-tls12"
then the min and max versions are TLS 1.0. But if a user has
"no-sslv3 no-tls11" then we don't know and we have to complain. Hopefully
it would affect very few users (those with strange setups or not aware of
their holes).

What bothers me with this API change is that it doesn't provide the same
flexibility. If you have a vulnerability coming with an implementation or
simply a known incompatibility and want to disable it and only this one,
you're screwed. With the previous API it was possible. That's why I'm
still not 100% sold on the API change :-/

Cheers,
Willy
Pavlos Parissis
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 08:30PM
On 14/03/2017 05:24 μμ, Willy Tarreau wrote:
> Hi Pavlos,
>
> On Tue, Mar 14, 2017 at 04:43:26PM +0100, Pavlos Parissis wrote:
>> Hi,
>>
>> On Debian testing with openssl 1.1.0e, I get the following warnings when I
>> compile 1.7 and 1.8:
>> https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt
>
> Yes these ones are known and for now we don't have any workaround. It
> seems openssl 1.1 wants us to drop support for older TLS versions, but
> we definitely can't do that so we'll have to live with the warnings :-/
> I couldn't find a way to make them disappear.
>

No worries, it compiles at the end and haproxy starts:-)

>> When I compile 1.6 I get errors and compilation fails:
>> https://gist.githubusercontent.com/unixsurfer/4476410bbbaf2192af591123f4388850/raw/a733808a3028f0c9d7f53f4e699da6de3ae18969/gistfile1.txt
>
> This is indeed expected, openssl 1.1's API is very different from 1.0.
>
>> I compile it with:
>> make clean;make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
>> USE_PCRE_JIT=1 USE_TPROXY=1
>>
>> Am I the only seeing these warnings/errors? Searched on ML and someone mentioned
>> that haproxy 1.6 wont support 1.1.0 version of openssl, is this accurate? Having
>> openssl 1.0.2 and 1.1.0 on my personal development machine is fine, so zero
>> problems here if 1.6 does not support openssl 1.1.0 version.
>
> Yes that's accurate. The risk of breakage is far too high for this to be
> backported to 1.6. With 1.7 not much different from 1.6, we'll have all
> people willing to explore openssl 1.1 users upgrade to haproxy 1.7 with
> very limited risks (and BTW some of the bugs currently affecting 1.7 are
> also on 1.6 and are in fact uncovered by some fixes for bugs that were
> hiding other ones).
>

I fully understand the situation, I will compile 1.6 against openssl 1.0.2 version
on my Debian testing box. I am not using 1.6 version at all, too old :-), but I am
reshuffling code in haproxyadmin python lib and I want to make sure it
works with older versions of haproxy.

Thanks for the reply,
Pavlos
Willy Tarreau
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 10:30PM
On Tue, Mar 14, 2017 at 08:18:27PM +0100, Pavlos Parissis wrote:
> >> On Debian testing with openssl 1.1.0e, I get the following warnings when I
> >> compile 1.7 and 1.8:
> >> https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt
> >
> > Yes these ones are known and for now we don't have any workaround. It
> > seems openssl 1.1 wants us to drop support for older TLS versions, but
> > we definitely can't do that so we'll have to live with the warnings :-/
> > I couldn't find a way to make them disappear.
> >
>
> No worries, it compiles at the end and haproxy starts:-)

Ah that's how I test it before releasing... Just kidding, I don't verify
that it starts :-)

(...)
> I fully understand the situation, I will compile 1.6 against openssl 1.0.2 version
> on my Debian testing box. I am not using 1.6 version at all, too old :-), but I am
> reshuffling code in haproxyadmin python lib and I want to make sure it
> works with older versions of haproxy.

OK cool! Just out of curiosity, are there some features of 1.7 that you've
already got used to and that prevent you from using 1.6, or is this just a
matter of staying on something modern ?

Cheers,
Willy
Pavlos Parissis
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 11:00PM
On 14/03/2017 10:20 μμ, Willy Tarreau wrote:
> On Tue, Mar 14, 2017 at 08:18:27PM +0100, Pavlos Parissis wrote:
>>>> On Debian testing with openssl 1.1.0e, I get the following warnings when I
>>>> compile 1.7 and 1.8:
>>>> https://gist.githubusercontent.com/unixsurfer/9c42361822f23cfe36f3b2169133b551/raw/4665476fdfb2a94d287814a2c8a36215cbebb465/gistfile1.txt
>>>
>>> Yes these ones are known and for now we don't have any workaround. It
>>> seems openssl 1.1 wants us to drop support for older TLS versions, but
>>> we definitely can't do that so we'll have to live with the warnings :-/
>>> I couldn't find a way to make them disappear.
>>>
>>
>> No worries, it compiles at the end and haproxy starts:-)
>
> Ah that's how I test it before releasing... Just kidding, I don't verify
> that it starts :-)
>
> (...)
>> I fully understand the situation, I will compile 1.6 against openssl 1.0.2 version
>> on my Debian testing box. I am not using 1.6 version at all, too old :-), but I am
>> reshuffling code in haproxyadmin python lib and I want to make sure it
>> works with older versions of haproxy.
>
> OK cool! Just out of curiosity, are there some features of 1.7 that you've
> already got used to and that prevent you from using 1.6, or is this just a
> matter of staying on something modern ?
>

The latter, I prefer to use the latest stable version. I usually wait 1 month
before I switch to the new stable release[1]. For instance, I switched from 1.5 to
1.6 when 1.6.3 was released. Switching to 1.7 takes more time because I have other
projects with higher priority.

[1] With the only exception of 1.5, I switched to 1.5.0 only a day after it was
released. Zero issues on production! But, I keep the config clean and very simple,
I hate unnecessary complexity.
Willy Tarreau
Re: Some compilation SSL errors/warnings on debian testing
March 14, 2017 11:20PM
On Tue, Mar 14, 2017 at 10:55:34PM +0100, Pavlos Parissis wrote:
> > Just out of curiosity, are there some features of 1.7 that you've
> > already got used to and that prevent you from using 1.6, or is this just a
> > matter of staying on something modern ?
> >
>
> The latter, I prefer to use the latest stable version. I usually wait 1 month
> before I switch to the new stable release[1]. For instance, I switched from 1.5 to
> 1.6 when 1.6.3 was released. Switching to 1.7 takes more time because I have other
> projects with higher priority.

OK that makes sense. In fact I do push the .0 in production on haproxy.org
in order to know and to show the example (eat my own food). But I agree
over time and due to the delays I tend to accumulate between older releases
you can sometimes be safer on a more recent branch. I've use to consider
that we needed about 4 versions before starting to think about blind
deployments, and that's approximately it. 1.5.4, 1.6.4 were getting better
and here we still discover annoying issues in 1.7.3 that will be fixed in
1.7.4 (some of them were already in 1.5 and 1.6 so we're improving).

> [1] With the only exception of 1.5, I switched to 1.5.0 only a day after it was
> released. Zero issues on production! But, I keep the config clean and very simple,
> I hate unnecessary complexity.

1.5 was different, it used to be production ready since dev7 without SSL
and dev17 if you used SSL :-) What a pain, I never want to do that again!

Cheers,
Willy
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 15, 2017 12:50PM
> Le 14 mars 2017 à 19:11, Willy Tarreau <[email protected]> a écrit :
>>
>> For the little story: openssl-1.1.0 and boringssl have SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version
>> and other methods to set protocol version are deprecated (or not implemented).
>> It will be boring to keep compat with haproxy ssl directive no-<method> and force-<method>.
>> And perhaps the add of some min-<method> and max-<method>.
>>
>> Willy, what do you think?
>
> Well, that means we'll definitely break all setups and piss-off users :-(
>
> What we can possibly do is to determine the appropriate min/max based on
> the existing no-<foo> and force-<foo> and complain if there are holes.
> Ie, if a user has "no-sslv3 no-tls10 no-tls11" then the min version is
> TLS 1.2 and that could work. If a user has "no-sslv3 no-tls11 no-tls12"
> then the min and max versions are TLS 1.0. But if a user has
> "no-sslv3 no-tls11" then we don't know and we have to complain. Hopefully
> it would affect very few users (those with strange setups or not aware of
> their holes).
> What bothers me with this API change is that it doesn't provide the same
> flexibility. If you have a vulnerability coming with an implementation or
> simply a known incompatibility and want to disable it and only this one,
> you're screwed. With the previous API it was possible. That's why I'm
> still not 100% sold on the API change :-/
>

ssl_options seems still valid, all directives can be mapped to it and keep compatibility.

Manu
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 15, 2017 05:10PM
> Le 15 mars 2017 à 12:41, Emmanuel Hocdet <[email protected]> a écrit :
>
>
>> Le 14 mars 2017 à 19:11, Willy Tarreau <[email protected] <mailto:[email protected]>> a écrit :
>>>
>>> For the little story: openssl-1.1.0 and boringssl have SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version
>>> and other methods to set protocol version are deprecated (or not implemented).
>>> It will be boring to keep compat with haproxy ssl directive no-<method> and force-<method>.
>>> And perhaps the add of some min-<method> and max-<method>.
>>>
>>> Willy, what do you think?
>>
>> Well, that means we'll definitely break all setups and piss-off users :-(
>>
>> What we can possibly do is to determine the appropriate min/max based on
>> the existing no-<foo> and force-<foo> and complain if there are holes.
>> Ie, if a user has "no-sslv3 no-tls10 no-tls11" then the min version is
>> TLS 1.2 and that could work. If a user has "no-sslv3 no-tls11 no-tls12"
>> then the min and max versions are TLS 1.0. But if a user has
>> "no-sslv3 no-tls11" then we don't know and we have to complain. Hopefully
>> it would affect very few users (those with strange setups or not aware of
>> their holes).
>> What bothers me with this API change is that it doesn't provide the same
>> flexibility. If you have a vulnerability coming with an implementation or
>> simply a known incompatibility and want to disable it and only this one,
>> you're screwed. With the previous API it was possible. That's why I'm
>> still not 100% sold on the API change :-/
>>
>
>
This usage is not recommended:

"The list of protocols available can also be limited using the SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 options of the SSL_CTX_set_options https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_options.html or SSL_set_options https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_options.html functions, but this approach is not recommended. Clients should avoid creating "holes" in the set of protocols they support. When disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions."
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 15, 2017 07:10PM
Hi Willy,

> Le 15 mars 2017 à 12:41, Emmanuel Hocdet <[email protected]> a écrit :
>
>
>> Le 14 mars 2017 à 19:11, Willy Tarreau <[email protected] <mailto:[email protected]>> a écrit :
>>>
>>> For the little story: openssl-1.1.0 and boringssl have SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version
>>> and other methods to set protocol version are deprecated (or not implemented).
>>> It will be boring to keep compat with haproxy ssl directive no-<method> and force-<method>.
>>> And perhaps the add of some min-<method> and max-<method>.
>>>
>>> Willy, what do you think?
>>
>> Well, that means we'll definitely break all setups and piss-off users :-(
>>
>> What we can possibly do is to determine the appropriate min/max based on
>> the existing no-<foo> and force-<foo> and complain if there are holes.
>> Ie, if a user has "no-sslv3 no-tls10 no-tls11" then the min version is
>> TLS 1.2 and that could work. If a user has "no-sslv3 no-tls11 no-tls12"
>> then the min and max versions are TLS 1.0. But if a user has
>> "no-sslv3 no-tls11" then we don't know and we have to complain. Hopefully
>> it would affect very few users (those with strange setups or not aware of
>> their holes).
>> What bothers me with this API change is that it doesn't provide the same
>> flexibility. If you have a vulnerability coming with an implementation or
>> simply a known incompatibility and want to disable it and only this one,
>> you're screwed. With the previous API it was possible. That's why I'm
>> still not 100% sold on the API change :-/
>>
>
> ssl_options seems still valid, all directives can be mapped to it and keep compatibility.
>

Patch proposal:
Attachments:
open | download - 0001-MEDIUM-ssl-rework-of-ssl_method-calculation-to-match.patch (20.6 KB)
Willy Tarreau
Re: Some compilation SSL errors/warnings on debian testing
March 15, 2017 07:10PM
Hi Manu,

On Wed, Mar 15, 2017 at 07:00:28PM +0100, Emmanuel Hocdet wrote:
> > ssl_options seems still valid, all directives can be mapped to it and keep compatibility.
> >
>
> Patch proposal:

Maybe it could work, let's wait for Emeric's feedback. I remember there
was a subtle difference between no-<version> and force-<version> but I
don't remember which one.

Thanks,
Willy
On 03/15/2017 07:06 PM, Willy Tarreau wrote:
> Hi Manu,
>
> On Wed, Mar 15, 2017 at 07:00:28PM +0100, Emmanuel Hocdet wrote:
>>> ssl_options seems still valid, all directives can be mapped to it and keep compatibility.
>>>
>>
>> Patch proposal:
>
> Maybe it could work, let's wait for Emeric's feedback. I remember there
> was a subtle difference between no-<version> and force-<version> but I
> don't remember which one.
>
> Thanks,
> Willy
>


I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.

I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.

So for me the patch could modify some behavior for openssl versions < 1.1

There is another point which worries me:

In the proposed patch, statement 'force-' will disable all known protocol version except that one.

But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.

R,
Emeric
Hi Manu,

On 03/16/2017 02:44 PM, Emeric Brun wrote:
> On 03/15/2017 07:06 PM, Willy Tarreau wrote:
>> Hi Manu,
>>
>> On Wed, Mar 15, 2017 at 07:00:28PM +0100, Emmanuel Hocdet wrote:
>>>> ssl_options seems still valid, all directives can be mapped to it and keep compatibility.
>>>>
>>>
>>> Patch proposal:
>>
>> Maybe it could work, let's wait for Emeric's feedback. I remember there
>> was a subtle difference between no-<version> and force-<version> but I
>> don't remember which one.
>>
>> Thanks,
>> Willy
>>
>
>
> I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.
>
> I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.
>
> So for me the patch could modify some behavior for openssl versions < 1.1
>
> There is another point which worries me:
>
> In the proposed patch, statement 'force-' will disable all known protocol version except that one.
>
> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>
> R,
> Emeric
>

Finally,

To avoid side effects as explained below, i think it would be better to use SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version, setting min = max to forced version
using 'force-' statements.
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 16, 2017 06:00PM
Hi Emeric,

> Le 16 mars 2017 à 14:44, Emeric Brun <[email protected]> a écrit :
>
> I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.
>
> I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.
>
> So for me the patch could modify some behavior for openssl versions < 1.1

I did not see any problems with 1.0.1, 1.0.2 documentation tends to say that it’s ok and 1.1.0 deprecated the haproxy ‘force’ implementation.
At worst, this can change something in openssl 0.9.x but it's for haproxy 1.8dev…
It seem that use SSL_CTX_set_options is a good compatibly choice.

The only thing i see is that no-tlsxx can generate a not recommented configuration (1.0.2).
"The list of protocols available can be further limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2options of the SSL_CTX_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html or SSL_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_options.html functions. Clients should avoid creating "holes" in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions."

Openssl introduce min-tlsxx max-tlsxx directives to avoid ‘holes’ configuration is equivalent to use SSL_CTX_set_options correctly.

> There is another point which worries me:
>
> In the proposed patch, statement 'force-' will disable all known protocol version except that one.
>
> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>
I agree, TLSv1.3 is missing. min-tlsxx max-tlsxx openssl directives will be a better way to no care about new version.
I have a second patch who add TLSv1.3 and min-tlsxx max-tlsxx haproxy directive (patch is ssl version agnostic).

++
Manu
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 17, 2017 06:50PM
> Le 16 mars 2017 à 17:49, Emmanuel Hocdet <[email protected]> a écrit :
>
> Hi Emeric,
>
>> Le 16 mars 2017 à 14:44, Emeric Brun <[email protected] <mailto:[email protected]>> a écrit :
>>
>> I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.
>>
>> I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.
>>
>> So for me the patch could modify some behavior for openssl versions < 1.1
>
> I did not see any problems with 1.0.1, 1.0.2 documentation tends to say that it’s ok and 1.1.0 deprecated the haproxy ‘force’ implementation.
> At worst, this can change something in openssl 0.9.x but it's for haproxy 1.8dev…
> It seem that use SSL_CTX_set_options is a good compatibly choice.
>
> The only thing i see is that no-tlsxx can generate a not recommented configuration (1.0.2).
> "The list of protocols available can be further limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2options of the SSL_CTX_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html or SSL_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_options.html functions. Clients should avoid creating "holes" in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions."
>
> Openssl introduce min-tlsxx max-tlsxx directives to avoid ‘holes’ configuration is equivalent to use SSL_CTX_set_options correctly.
>
>> There is another point which worries me:
>>
>> In the proposed patch, statement 'force-' will disable all known protocol version except that one.
>>
>> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>>
> I agree, TLSv1.3 is missing. min-tlsxx max-tlsxx openssl directives will be a better way to no care about new version.
> I have a second patch who add TLSv1.3 and min-tlsxx max-tlsxx haproxy directive (patch is ssl version agnostic).
>
With this patches, all tls versions are supported and it’s easy to add new tls version internally.
min-tlsxx and max-tlsxx is supported for all ssllibs: configuration will be more clear that with no-tlsxx and without « holes ».
Add SSL_CTX_set_min/max_proto_version could be a option but i does not see the necessity.

Manu
Attachments:
open | download - 0001-MEDIUM-ssl-rework-of-ssl_method-calculation-to-match.patch (20.6 KB)
open | download - 0002-MEDIUM-ssl-add-TLSv1.3-directives-and-min-method-max.patch (37.5 KB)
Hi Manu,

On 03/17/2017 06:43 PM, Emmanuel Hocdet wrote:
>
>> Le 16 mars 2017 à 17:49, Emmanuel Hocdet <[email protected] <mailto:[email protected]>> a écrit :
>>
>> Hi Emeric,
>>
>>> Le 16 mars 2017 à 14:44, Emeric Brun <[email protected] <mailto:[email protected]>> a écrit :
>>>
>>> I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.
>>>
>>> I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.
>>>
>>> So for me the patch could modify some behavior for openssl versions < 1.1
>>
>> I did not see any problems with 1.0.1, 1.0.2 documentation tends to say that it’s ok and 1.1.0 deprecated the haproxy ‘force’ implementation.
>> At worst, this can change something in openssl 0.9.x but it's for haproxy 1.8dev…
>> It seem that use SSL_CTX_set_options is a good compatibly choice.
>>
>> The only thing i see is that no-tlsxx can generate a not recommented configuration (1.0.2).
>> "The list of protocols available can be further limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2options of the SSL_CTX_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html or SSL_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_options.html functions. Clients should avoid creating "holes" in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions."
>>
>> Openssl introduce min-tlsxx max-tlsxx directives to avoid ‘holes’ configuration is equivalent to use SSL_CTX_set_options correctly.
>>
>>> There is another point which worries me:
>>>
>>> In the proposed patch, statement 'force-' will disable all known protocol version except that one.
>>>
>>> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>>>
>> I agree, TLSv1.3 is missing. min-tlsxx max-tlsxx openssl directives will be a better way to no care about new version.
>> I have a second patch who add TLSv1.3 and min-tlsxx max-tlsxx haproxy directive (patch is ssl version agnostic).
>>
> With this patches, all tls versions are supported and it’s easy to add new tls version internally.
> min-tlsxx and max-tlsxx is supported for all ssllibs: configuration will be more clear that with no-tlsxx and without « holes ».
> Add SSL_CTX_set_min/max_proto_version could be a option but i does not see the necessity.
>
> Manu
>
>

I'm still thinking that SSL_set_min/max_proto_version are a better approach to handle 'force-' options for openssl version >= 1.1 . Less intrusive for older openssl's versions and without any doubt on what they gonna do even if new protocols versions would appear.

R,
Emeric
Hi Manu,

On 03/20/2017 11:46 AM, Emeric Brun wrote:
> Hi Manu,
>
> On 03/17/2017 06:43 PM, Emmanuel Hocdet wrote:
>>
>>> Le 16 mars 2017 à 17:49, Emmanuel Hocdet <[email protected] <mailto:[email protected]>> a écrit :
>>>
>>> Hi Emeric,
>>>
>>>> Le 16 mars 2017 à 14:44, Emeric Brun <[email protected] <mailto:[email protected]>> a écrit :
>>>>
>>>> I'm clearly not sure that setting openssl's options to ~no-tlsxx have the same behavior than forcing the callback sets (using force-) to one protocol.
>>>>
>>>> I always suspected that no-tlsxx options applies on a kind of 'capabilities' where as setting a callback-set clearly force the usage of a protocol version.
>>>>
>>>> So for me the patch could modify some behavior for openssl versions < 1.1
>>>
>>> I did not see any problems with 1.0.1, 1.0.2 documentation tends to say that it’s ok and 1.1.0 deprecated the haproxy ‘force’ implementation.
>>> At worst, this can change something in openssl 0.9.x but it's for haproxy 1.8dev…
>>> It seem that use SSL_CTX_set_options is a good compatibly choice.
>>>
>>> The only thing i see is that no-tlsxx can generate a not recommented configuration (1.0.2).
>>> "The list of protocols available can be further limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2options of the SSL_CTX_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html or SSL_set_options https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_options.html functions. Clients should avoid creating "holes" in the set of protocols they support, when disabling a protocol, make sure that you also disable either all previous or all subsequent protocol versions. In clients, when a protocol version is disabled without disabling all previous protocol versions, the effect is to also disable all subsequent protocol versions."
>>>
>>> Openssl introduce min-tlsxx max-tlsxx directives to avoid ‘holes’ configuration is equivalent to use SSL_CTX_set_options correctly.
>>>
>>>> There is another point which worries me:
>>>>
>>>> In the proposed patch, statement 'force-' will disable all known protocol version except that one.
>>>>
>>>> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>>>>
>>> I agree, TLSv1.3 is missing. min-tlsxx max-tlsxx openssl directives will be a better way to no care about new version.
>>> I have a second patch who add TLSv1.3 and min-tlsxx max-tlsxx haproxy directive (patch is ssl version agnostic).
>>>
>> With this patches, all tls versions are supported and it’s easy to add new tls version internally.
>> min-tlsxx and max-tlsxx is supported for all ssllibs: configuration will be more clear that with no-tlsxx and without « holes ».
>> Add SSL_CTX_set_min/max_proto_version could be a option but i does not see the necessity.
>>
>> Manu
>>
>>
>
> I'm still thinking that SSL_set_min/max_proto_version are a better approach to handle 'force-' options for openssl version >= 1.1 . Less intrusive for older openssl's versions and without any doubt on what they gonna do even if new protocols versions would appear.
>
> R,
> Emeric
>
Something like that (see attachment).

R,
Emeric
Emmanuel Hocdet
Re: Some compilation SSL errors/warnings on debian testing
March 20, 2017 07:10PM
Hi Emeric,

> Le 20 mars 2017 à 12:50, Emeric Brun <[email protected]> a écrit :
>
> Hi Manu,
>
> On 03/20/2017 11:46 AM, Emeric Brun wrote:
>> Hi Manu,
>>
>> On 03/17/2017 06:43 PM, Emmanuel Hocdet wrote:
>>>
>>>> Le 16 mars 2017 à 17:49, Emmanuel Hocdet <[email protected] <mailto:[email protected]>> a écrit :
>>>>
>>>> Hi Emeric,
>>>>
>>> With this patches, all tls versions are supported and it’s easy to add new tls version internally.
>>> min-tlsxx and max-tlsxx is supported for all ssllibs: configuration will be more clear that with no-tlsxx and without « holes ».
>>> Add SSL_CTX_set_min/max_proto_version could be a option but i does not see the necessity.
>>>
>>> Manu
>>>
>>>
>>
>> I'm still thinking that SSL_set_min/max_proto_version are a better approach to handle 'force-' options for openssl version >= 1.1 . Less intrusive for older openssl's versions and without any doubt on what they gonna do even if new protocols versions would appear.
>>
>> R,
>> Emeric
>>
> Something like that (see attachment).
>

Yes, i understood.
I prefer the abstraction on the flagging versions. It's more simpler to add min-xx max-xx: the configuration is more consistent than no-xxx (and avoid 'holes').
Requirements to not change old implementations of force-xx and fix the max version can be addressed with my patches. I have one that happens.

++
Manu
Emmanuel Hocdet
[Patches] TLS methods configuration reworked
March 22, 2017 04:40PM
Hi Emeric,

Patches is a rework of TLS methods configuration.
Goal is to abstract haproxy TLS methods configuration and openssl configuration requirements (versions dependant)
This will make it easier to update and make the configuration less ambiguous.
0001 unify no-tlsxx force-tlsxx with bit flags, configure openssl with set options (version agnostic)
0002 add min-tlsxx max-tlsxx and TLSv1.3 initial support
SSL negotiation requires contiguous TLS versions. openssl 1.1.0 API add min/max call for that.
min/max is also a more suitable parameter to keep configuration consistent across haproxy/openssl versions.
Note: min/max should replace no-tlsxx usage (and can replace force-tlsxx usage)
0003 Warning when all TLS methods are disabled
0004 improve haproxy -vvv with TLS methods
0005 force-tlsxx implementation compatibility (Emeric first point)

For the second point
> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.

I can provide a patch for that but it will not useful for years until a new TLS will be implemented. It can generate build breaks until this time.
.. all TLS methods are known in haproxy (set_options usage is safe)
.. Haproxy must be run with the same version as the compilation. Change the openssl version (other than for bug fix) is not supported.

> Le 20 mars 2017 à 19:07, Emmanuel Hocdet <[email protected]> a écrit :
>
> Yes, i understood.
> I prefer the abstraction on the flagging versions. It's more simpler to add min-xx max-xx: the configuration is more consistent than no-xxx (and avoid 'holes').
> Requirements to not change old implementations of force-xx and fix the max version can be addressed with my patches. I have one that happens.

patches up to date:

++
Manu
Attachments:
open | download - 0001-MEDIUM-ssl-rework-of-ssl_methods-calculation-to-matc.patch (19 KB)
open | download - 0002-MEDIUM-ssl-add-TLSv1.3-directives-and-min-method-max.patch (37.7 KB)
open | download - 0003-MINOR-ssl-warm-when-all-SSL-TLS-versions-are-disable.patch (2.1 KB)
open | download - 0004-MINOR-ssl-show-methods-supported-by-openssl.patch (1.3 KB)
open | download - 0005-MINOR-ssl-keep-force-tlsxx-implementation-as-it-is-i.patch (3.6 KB)
Emmanuel Hocdet
Re: [Patches] TLS methods configuration reworked
March 22, 2017 06:30PM
> Le 22 mars 2017 à 16:30, Emmanuel Hocdet <[email protected]> a écrit :
> […]
> 0005 force-tlsxx implementation compatibility (Emeric first point)
>
> For the second point
>> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>
> I can provide a patch for that but it will not useful for years until a new TLS will be implemented. It can generate build breaks until this time.
> . all TLS methods are known in haproxy (set_options usage is safe)
> . Haproxy must be run with the same version as the compilation. Change the openssl version (other than for bug fix) is not supported.

By testing TLSv1.3 i noticed that per default, the version is disable and can’t be used until SSL_CTX_set_max_proto_version is set with TLS1_3_VERSION.
So i will add a patch for SSL_CTX_set_max_proto_version with TLSv1.3 disable per default.

This look like what you might have encountered with initial openssl development and force-tlsxx: activate a pending TLS version.
Does that tell you something Emeric?

Manu
Emeric Brun
Re: [Patches] TLS methods configuration reworked
March 23, 2017 03:40PM
Hi Manu,

On 03/22/2017 06:24 PM, Emmanuel Hocdet wrote:
>
>> Le 22 mars 2017 à 16:30, Emmanuel Hocdet <[email protected]> a écrit :
>> […]
>> 0005 force-tlsxx implementation compatibility (Emeric first point)
>>
>> For the second point
>>> But we will face issue using 'force-' when openssl will support further tls versions not yet handled by haproxy. This problem was correctly handled by the previous implementation.
>>
>> I can provide a patch for that but it will not useful for years until a new TLS will be implemented. It can generate build breaks until this time.
>> . all TLS methods are known in haproxy (set_options usage is safe)
>> . Haproxy must be run with the same version as the compilation. Change the openssl version (other than for bug fix) is not supported.
>
> By testing TLSv1.3 i noticed that per default, the version is disable and can’t be used until SSL_CTX_set_max_proto_version is set with TLS1_3_VERSION.
> So i will add a patch for SSL_CTX_set_max_proto_version with TLSv1.3 disable per default.
>
> This look like what you might have encountered with initial openssl development and force-tlsxx: activate a pending TLS version.
> Does that tell you something Emeric?
>
> Manu
>
>
>

I said that using SSL_CTX_set_max_proto_version and SSL_CTX_set_min_proto_version to handle force-tlsxx will keep it compliant for any newcoming protocol version.

Using ~knownbitflags is not the case cause you have to predict further versions, to disable them.

R,
Emeric
Emmanuel Hocdet
Re: [Patches] TLS methods configuration reworked
March 24, 2017 07:20PM
Hi Emeric,
patches serie updated. The new one is 0004.
It should match what you are requesting and what I observed in the openssl code.

++
Manu
Attachments:
open | download - 0001-MEDIUM-ssl-rework-of-ssl_methods-calculation-to-matc.patch (19 KB)
open | download - 0002-MEDIUM-ssl-add-TLSv1.3-directives-and-min-method-max.patch (37.7 KB)
open | download - 0003-MINOR-ssl-show-methods-supported-by-openssl.patch (1.3 KB)
open | download - 0004-MEDIUM-ssl-rework-ssl_methods-settings-with-openssl-.patch (8.3 KB)
Igor Pav
Re: [Patches] TLS methods configuration reworked
March 26, 2017 06:00PM
Hi, Emmanuel. Any plan to add tls 1.3 zero rtt support for both server
and client side?

On Sat, Mar 25, 2017 at 2:13 AM, Emmanuel Hocdet <[email protected]> wrote:
>
> Hi Emeric,
> patches serie updated. The new one is 0004.
> It should match what you are requesting and what I observed in the openssl code.
>
> ++
> Manu
>
>
Sorry, only registered users may post in this forum.

Click here to login