Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Hi Emeric,

> Le 20 mars 2017 à 12:50, Emeric Brun  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 > 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

Re: Some compilation SSL errors/warnings on debian testing

[Emeric Brun]

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 >> > a écrit :
>>>
>>> Hi Emeric,
>>>
 Le 16 mars 2017 à 14:44, Emeric Brun > 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 
>>>  or 
>>> SSL_set_options 
>>>  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

>From 87612555e61b1804985bc1d012ca1d611ceb5932 Mon Sep 17 00:00:00 2001
From: Emeric Brun 
Date: Mon, 20 Mar 2017 12:45:44 +0100
Subject: [PATCH] MINOR: fix deprecated warnings on ssl methods using openssl
 1.1.
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

Calls to deprecated method functions was replaced using
SSL_CTX_set_min_proto_version and SSL_CTX_set_max_proto_version.
---
 src/ssl_sock.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index f947c99..ffed5e7 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -3188,6 +3188,28 @@ ssl_sock_initial_ctx(struct bind_conf *bind_conf)
 		SSL_MODE_SMALL_BUFFERS;
 	int conf_ssl_options = bind_conf->ssl_options;
 
+#ifdef SSL_CTX_set_min_proto_version
+	if (!ctx && conf_ssl_options & BC_SSL_O_USE_TLSV12) {
+		ctx = SSL_CTX_new(SSLv23_server_method());
+		SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);
+		SSL_CTX_set_max_proto_version(ctx, TLS1_2_VERSION);
+	}
+	if (!ctx && conf_ssl_options & BC_SSL_O_USE_TLSV11) {
+		ctx = SSL_CTX_new(SSLv23_server_method());
+		SSL_CTX_set_min_proto_version(ctx, TLS1_1_VERSION);
+		SSL_CTX_set_max_proto_version(ctx, TLS1_1_VERSION);
+	}
+	if (!ctx && conf_ssl_options & BC_SSL_O_USE_TLSV10) {
+		ctx = SSL_CTX_new(SSLv23_server_method());
+		SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION);
+		SSL_CTX_set_max_proto_version(ctx, TLS1_VERSION);
+	}
+	if (!ctx && conf_ssl_options & BC_SSL_O_USE_SSLV3) {
+		ctx = 

Re: Some compilation SSL errors/warnings on debian testing

[Emeric Brun]

Hi Manu,

On 03/17/2017 06:43 PM, Emmanuel Hocdet wrote:
> 
>> Le 16 mars 2017 à 17:49, Emmanuel Hocdet > > a écrit :
>>
>> Hi Emeric,
>>
>>> Le 16 mars 2017 à 14:44, Emeric Brun >> > 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 
>>  or 
>> SSL_set_options 
>>  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

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Le 16 mars 2017 à 17:49, Emmanuel Hocdet  a écrit :Hi Emeric,Le 16 mars 2017 à 14:44, Emeric Brun  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.1I 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 or SSL_set_options 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

0001-MEDIUM-ssl-rework-of-ssl_method-calculation-to-match.patch
Description: Binary data


0002-MEDIUM-ssl-add-TLSv1.3-directives-and-min-method-max.patch
Description: Binary data

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Hi Emeric,

> Le 16 mars 2017 à 14:44, Emeric Brun  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 
 or 
SSL_set_options 
 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

Re: Some compilation SSL errors/warnings on debian testing

[Emeric Brun]

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- and force- 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.

Re: Some compilation SSL errors/warnings on debian testing

[Emeric Brun]

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- and force- 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

Re: Some compilation SSL errors/warnings on debian testing

[Willy Tarreau]

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- and force- but I
don't remember which one.

Thanks,
Willy

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Hi Willy,Le 15 mars 2017 à 12:41, Emmanuel Hocdet  a écrit :Le 14 mars 2017 à 19:11, Willy Tarreau  a écrit :For the little story: openssl-1.1.0 and boringssl have SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_versionand other methods to set protocol version are deprecated (or not implemented).It will be boring to keep compat with haproxy ssl directive no- and force-.And perhaps the add of some min- and max-.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 onthe existing no- and force- and complain if there are holes.Ie, if a user has "no-sslv3 no-tls10 no-tls11" then the min version isTLS 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. Hopefullyit would affect very few users (those with strange setups or not aware oftheir holes).What bothers me with this API change is that it doesn't provide the sameflexibility. If you have a vulnerability coming with an implementation orsimply 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'mstill not 100% sold on the API change :-/ssl_options seems still valid, all directives can be mapped to it and keep compatibility.Patch proposal:

0001-MEDIUM-ssl-rework-of-ssl_method-calculation-to-match.patch
Description: Binary data

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

> Le 15 mars 2017 à 12:41, Emmanuel Hocdet  a écrit :
> 
> 
>> Le 14 mars 2017 à 19:11, Willy Tarreau > 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- and 
>>> force-.
>>> And perhaps the add of some min- and max-.
>>> 
>>> 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- and force- 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 
 or 
SSL_set_options 
 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."

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

> Le 14 mars 2017 à 19:11, Willy Tarreau  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- and 
>> force-.
>> And perhaps the add of some min- and max-.
>> 
>> 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- and force- 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

Re: Some compilation SSL errors/warnings on debian testing

[Willy Tarreau]

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

Re: Some compilation SSL errors/warnings on debian testing

[Pavlos Parissis]

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.



signature.asc
Description: OpenPGP digital signature

Re: Some compilation SSL errors/warnings on debian testing

[Willy Tarreau]

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

Re: Some compilation SSL errors/warnings on debian testing

[Pavlos Parissis]

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



signature.asc
Description: OpenPGP digital signature

Re: Some compilation SSL errors/warnings on debian testing

[Willy Tarreau]

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  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- and 
> force-.
> And perhaps the add of some min- and max-.
> 
> 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- and force- 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

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Hi Willy,

> Le 14 mars 2017 à 17:24, Willy Tarreau  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

Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Hi Pavlos

> Le 14 mars 2017 à 16:43, Pavlos Parissis  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- and 
force-.
And perhaps the add of some min- and max-.

Willy, what do you think?

Manu

Re: Some compilation SSL errors/warnings on debian testing

[Willy Tarreau]

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

Some compilation SSL errors/warnings on debian testing

[Pavlos Parissis]

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



signature.asc
Description: OpenPGP digital signature