Re: OpenSSL 1.1.0 support => merged

[Dirkjan Bussink]

Hi Willy,

Thanks for getting this merged!

Cheers,

Dirkjan

> On 8 Nov 2016, at 13:12, Willy Tarreau  wrote:
> 
> Hi Dirkjan,
> 
> I finally merged your patch after discussing with Emeric. He's fine with
> it as well. Both of us think that the breakage of openssl 0.9.8 is not a
> showstopper at the moment and that the best way to know if/how it needs to
> be fixed is to let it go in the wild. Given that openssl 1.1.0 was released
> 3 months ago and 0.9.8 has been dead for almost a year, I prefer that our
> new haproxy version focuses on the future than on the past, especially with
> the reduced life of new versions (eg: 1.0.2 only has two more years left).
> 
> I got two annoying warnings affecting either older versions or newer ones,
> each time due to a const being put at the right place in a function prototype.
> So I added another patch to deal with this, it defines a new macro called
> __OPENSSL_110_CONST__ which equals "const" on 1.1.0 and nothing on older
> versions. 
> 
> I also moved the include file to include/proto/openssl-compat.h since it
> only defines prototypes. But the main reason I must confess is that the
> previous choice (include/compat/openssl.h) was causing me a lot of pain by
> breaking my auto-completion, and after spending a few hours on it, I had
> to forfeit on trying to get my fingers to switch "comm" instead of the
> shorter "c" they've been trained to for a decade :-/
> 
> I'm appending the 3 patches I added on top of yours and that I merged as
> one single patch. As you said, 1.1.0 builds with a few "deprecated" warnings
> which are still OK for now as the affected functions are part of the API and
> that we can clean later. I tested 1.0.1 and 1.0.2 and they were OK as well.
> 
> Now if anyone is interested in trying to port the code to 0.9.8 (should not be
> too hard, just a few more #ifdef to add), proposals are welcome.
> 
> Thanks!
> Willy
> <0001-WIP-ssl-1.1.0-protect-compat-openssl.h-against-multi.patch><0002-WIP-ssl-1.1.0-add-a-const-type-modifier-only-for-1.1.patch><0003-WIP-ssl-1.1.0-move-include-to-proto-openssl-compat.h.patch>

Re: OpenSSL 1.1.0 support => merged

[Willy Tarreau]

On Wed, Nov 09, 2016 at 01:28:07PM +0200, Apollon Oikonomopoulos wrote:
> Let's say that we must have settled with a stable-enough version by 
> early December. Is there a chance there will be a final 1.7 release by 
> then?

Definitely. I hope to have it maybe at the end of next week. Given
that I'm always late when releasing compared to what I announce, use
end of month as a safe target :-)

Cheers,
Willy

Re: OpenSSL 1.1.0 support => merged

[Apollon Oikonomopoulos]

On 12:07 Wed 09 Nov , Willy Tarreau wrote:
> On Wed, Nov 09, 2016 at 11:44:41AM +0200, Apollon Oikonomopoulos wrote:
> > Thanks for this. Is it too much of a hassle to ask for a 1.6 backport?
> 
> Given that it breaks support for older versions (0.9.8 at least), for
> now it's out of question. And it has received only limited testing. If
> we manage to stabilise the patch to properly handle all versions where
> 1.6 currently works, then maybe the question could be reconsidered.

Agreed, thanks for the clarification.

> 
> > We currently have a release-critical bug in Debian for OpenSSL 1.1 
> > compatibility[1], so it would greatly help us. I could go ahead and try 
> > to make a backport myself, however I admit I'm a bit reluctant to touch 
> > OpenSSL-related code at this point.
> 
> You should definitely avoid it, the testing is insufficient for now.
> 
> Another, better option would be to upgrade the haproxy package to 1.7 for
> the next debian release so that it matches the new openssl version as well.
> There are (too) few changes in 1.7 compared to 1.6, it mostly accumulated
> all the fixes that resulted from the bugs coming with the new architecture
> brought in 1.6. I consider 1.7 almost as stable as 1.6, and will encourage
> users to upgrade. I don't know how much time left you have to decide on a
> version for a new distro (I don't know the process at all).

Let's say that we must have settled with a stable-enough version by 
early December. Is there a chance there will be a final 1.7 release by 
then?

Regards,
Apollon

Re: OpenSSL 1.1.0 support => merged

[Willy Tarreau]

On Wed, Nov 09, 2016 at 11:44:41AM +0200, Apollon Oikonomopoulos wrote:
> Hi Willy, Dirkjan,
> 
> On 21:12 Tue 08 Nov , Willy Tarreau wrote:
> > Hi Dirkjan,
> > 
> > I finally merged your patch after discussing with Emeric. He's fine with
> > it as well.
> 
> Thanks for this. Is it too much of a hassle to ask for a 1.6 backport?

Given that it breaks support for older versions (0.9.8 at least), for
now it's out of question. And it has received only limited testing. If
we manage to stabilise the patch to properly handle all versions where
1.6 currently works, then maybe the question could be reconsidered.

> We currently have a release-critical bug in Debian for OpenSSL 1.1 
> compatibility[1], so it would greatly help us. I could go ahead and try 
> to make a backport myself, however I admit I'm a bit reluctant to touch 
> OpenSSL-related code at this point.

You should definitely avoid it, the testing is insufficient for now.

Another, better option would be to upgrade the haproxy package to 1.7 for
the next debian release so that it matches the new openssl version as well.
There are (too) few changes in 1.7 compared to 1.6, it mostly accumulated
all the fixes that resulted from the bugs coming with the new architecture
brought in 1.6. I consider 1.7 almost as stable as 1.6, and will encourage
users to upgrade. I don't know how much time left you have to decide on a
version for a new distro (I don't know the process at all).

Thanks,
Willy

Re: OpenSSL 1.1.0 support => merged

[Apollon Oikonomopoulos]

Hi Willy, Dirkjan,

On 21:12 Tue 08 Nov , Willy Tarreau wrote:
> Hi Dirkjan,
> 
> I finally merged your patch after discussing with Emeric. He's fine with
> it as well.

Thanks for this. Is it too much of a hassle to ask for a 1.6 backport?

We currently have a release-critical bug in Debian for OpenSSL 1.1 
compatibility[1], so it would greatly help us. I could go ahead and try 
to make a backport myself, however I admit I'm a bit reluctant to touch 
OpenSSL-related code at this point.

Thanks!
Apollon

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828337

Re: OpenSSL 1.1.0 support => merged

[Willy Tarreau]

Hi Dirkjan,

I finally merged your patch after discussing with Emeric. He's fine with
it as well. Both of us think that the breakage of openssl 0.9.8 is not a
showstopper at the moment and that the best way to know if/how it needs to
be fixed is to let it go in the wild. Given that openssl 1.1.0 was released
3 months ago and 0.9.8 has been dead for almost a year, I prefer that our
new haproxy version focuses on the future than on the past, especially with
the reduced life of new versions (eg: 1.0.2 only has two more years left).

I got two annoying warnings affecting either older versions or newer ones,
each time due to a const being put at the right place in a function prototype.
So I added another patch to deal with this, it defines a new macro called
__OPENSSL_110_CONST__ which equals "const" on 1.1.0 and nothing on older
versions. 

I also moved the include file to include/proto/openssl-compat.h since it
only defines prototypes. But the main reason I must confess is that the
previous choice (include/compat/openssl.h) was causing me a lot of pain by
breaking my auto-completion, and after spending a few hours on it, I had
to forfeit on trying to get my fingers to switch "comm" instead of the
shorter "c" they've been trained to for a decade :-/

I'm appending the 3 patches I added on top of yours and that I merged as
one single patch. As you said, 1.1.0 builds with a few "deprecated" warnings
which are still OK for now as the affected functions are part of the API and
that we can clean later. I tested 1.0.1 and 1.0.2 and they were OK as well.

Now if anyone is interested in trying to port the code to 0.9.8 (should not be
too hard, just a few more #ifdef to add), proposals are welcome.

Thanks!
Willy
>From 334cffc47313355e2f7573919b790be5d2e95d43 Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Tue, 8 Nov 2016 19:53:01 +0100
Subject: WIP: ssl-1.1.0: protect compat/openssl.h against multiple inclusion
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

---
 include/compat/openssl.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/compat/openssl.h b/include/compat/openssl.h
index 269df33..930f16f 100644
--- a/include/compat/openssl.h
+++ b/include/compat/openssl.h
@@ -1,3 +1,5 @@
+#ifndef _COMPAT_OPENSSL_H
+#define _COMPAT_OPENSSL_H
 #include 
 #include 
 #include 
@@ -130,3 +132,5 @@ static inline X509_ALGOR *X509_get0_tbs_sigalg(const X509 
*x)
 }
 
 #endif
+
+#endif /* _COMPAT_OPENSSL_H */
-- 
1.7.12.1

>From 25858b36486ff3278851c27a2903a670f2bd51e1 Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Tue, 8 Nov 2016 19:56:48 +0100
Subject: WIP: ssl-1.1.0: add a const type modifier only for 1.1.0
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

---
 include/compat/openssl.h | 6 ++
 src/shctx.c  | 2 +-
 src/ssl_sock.c   | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/compat/openssl.h b/include/compat/openssl.h
index 930f16f..7f86836 100644
--- a/include/compat/openssl.h
+++ b/include/compat/openssl.h
@@ -133,4 +133,10 @@ static inline X509_ALGOR *X509_get0_tbs_sigalg(const X509 
*x)
 
 #endif
 
+#if (OPENSSL_VERSION_NUMBER >= 0x101fL)
+#define __OPENSSL_110_CONST__ const
+#else
+#define __OPENSSL_110_CONST__
+#endif
+
 #endif /* _COMPAT_OPENSSL_H */
diff --git a/src/shctx.c b/src/shctx.c
index 39ca450..8485057 100644
--- a/src/shctx.c
+++ b/src/shctx.c
@@ -434,7 +434,7 @@ err:
 }
 
 /* SSL callback used on lookup an existing session cause none found in 
internal cache */
-SSL_SESSION *shctx_get_cb(SSL *ssl, unsigned char *key, int key_len, int 
*do_copy)
+SSL_SESSION *shctx_get_cb(SSL *ssl, __OPENSSL_110_CONST__ unsigned char *key, 
int key_len, int *do_copy)
 {
struct shared_session *shsess;
unsigned char data[SHSESS_MAX_DATA_LEN], *p;
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index d23bd87..1a02291 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -4643,7 +4643,7 @@ smp_fetch_ssl_x_sig_alg(const struct arg *args, struct 
sample *smp, const char *
 {
int cert_peer = (kw[4] == 'c') ? 1 : 0;
X509 *crt;
-   ASN1_OBJECT *algorithm;
+   __OPENSSL_110_CONST__ ASN1_OBJECT *algorithm;
int nid;
struct connection *conn;
 
-- 
1.7.12.1

>From ff9a0172ea7f5468cfcf89452dfe6c129f27a96b Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Tue, 8 Nov 2016 20:52:44 +0100
Subject: WIP: ssl-1.1.0: move include to proto/openssl-compat.h
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

it's really only prototypes, and the real reason is that having this
new "compat" subdirectory makes my auto-completion really painful now :-(
---
 include/compat/openssl.h   | 142 -
 include/proto/openssl-compat.h | 142 +
 src/shctx.c|   2 +-
 src/ssl_sock.c |   3 +-
 4 files changed, 144 

Re: OpenSSL 1.1.0 support

[Willy Tarreau]

Just resending, I noticed that my message didn't make it through the list,
and no, it was not caught by the anti-spam :-)

On Mon, Nov 07, 2016 at 08:19:06PM +0100, Willy Tarreau wrote:
> Hi Dirkjan,
> 
> On Mon, Nov 07, 2016 at 01:02:33PM +0100, Dirkjan Bussink wrote:
> > Hi Willy,
> > 
> > > On 26 Oct 2016, at 11:40, Willy Tarreau  wrote:
> > > 
> > > Yes I'd rather have it work with 0.9.8 as it's still supported and used by
> > > some LTS distros. For example, RHEL5's regular support is due till March 
> > > 2017
> > > and extended support till november 2020. It's not very likely that such 
> > > users
> > > will decide to upgrade to 1.7 now especially since some of the SSL-related
> > > features only work with newer versions. But if we can make it work as it 
> > > used
> > > to with limited effort it's better. Is your current patch capable of 
> > > supporting
> > > 0.9.8 ?
> > 
> > I don't think there's a reason it couldn't work. I haven't tested it though 
> > yet, only against 1.0.1 and 1.1.0 at this point. 
> 
> OK so I got a few build errors with openssl-0.9.8za but I think they're
> not impossible to get rid of, because every time it was just a matter of
> having some of these functions already declard in openssl (which sounds
> quite strange), hence the "conflicting type" declaration. What I don't
> understand is why I do find them both in 0.9.8 and 1.0.1 still they don't
> cause this build failure in 1.0.1. Any insight would be welcome, as I'm
> sure we're pretty close from something working. I checked the sources and
> didn't see any suspicious #if. Maybe we should rearrange our own 
> compat/openssl
> so that we don't redefine them on 0.9.8 ? I have not tested on 1.0.0 either
> but I think it's really dead even on LTS distros.
> 
> Thanks,
> Willy
> 
> 
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h:31:36: error: static declaration of 
> 'SSL_SESSION_get_id' follows non-static declaration
> In file included from src/ssl_sock.c:43:0:
> /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:1433:22: note: previous 
> declaration of 'SSL_SESSION_get_id' was here
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h:37:32: error: conflicting types for 
> 'X509_NAME_get_entry'
> In file included from /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:183:0,
>  from src/ssl_sock.c:43:
> /dev/shm/openssl-0.9.8za/include/openssl/x509.h:1106:18: note: previous 
> declaration of 'X509_NAME_get_entry' was here
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h:42:28: error: conflicting types for 
> 'X509_NAME_ENTRY_get_object'
> In file included from /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:183:0,
>  from src/ssl_sock.c:43:
> /dev/shm/openssl-0.9.8za/include/openssl/x509.h:1127:15: note: previous 
> declaration of 'X509_NAME_ENTRY_get_object' was here
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h:47:28: error: conflicting types for 
> 'X509_NAME_ENTRY_get_data'
> In file included from /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:183:0,
>  from src/ssl_sock.c:43:
> /dev/shm/openssl-0.9.8za/include/openssl/x509.h:1128:15: note: previous 
> declaration of 'X509_NAME_ENTRY_get_data' was here
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h:52:19: error: conflicting types for 
> 'ASN1_STRING_length'
> In file included from 
> /dev/shm/openssl-0.9.8za/include/openssl/objects.h:960:0,
>  from /dev/shm/openssl-0.9.8za/include/openssl/evp.h:98,
>  from /dev/shm/openssl-0.9.8za/include/openssl/x509.h:73,
>  from /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:183,
>  from src/ssl_sock.c:43:
> /dev/shm/openssl-0.9.8za/include/openssl/asn1.h:795:5: note: previous 
> declaration of 'ASN1_STRING_length' was here
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h:57:19: error: static declaration of 
> 'X509_NAME_entry_count' follows non-static declaration
> In file included from /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:183:0,
>  from src/ssl_sock.c:43:
> /dev/shm/openssl-0.9.8za/include/openssl/x509.h:1095:7: note: previous 
> declaration of 'X509_NAME_entry_count' was here
> In file included from src/ssl_sock.c:56:0:
> include/compat/openssl.h: In function 'X509_NAME_entry_count':
> include/compat/openssl.h:60:1: error: expected ';' before '}' token
> include/compat/openssl.h: At top level:
> include/compat/openssl.h:68:20: error: conflicting types for 'X509_ALGOR_get0'
> In file included from /dev/shm/openssl-0.9.8za/include/openssl/ssl.h:183:0,
>  from src/ssl_sock.c:43:
> /dev/shm/openssl-0.9.8za/include/openssl/x509.h:871:6: note: previous 
> declaration of 'X509_ALGOR_get0' was here
> In file included from src/shctx.c:30:0:
> include/compat/openssl.h:31:36: error: static 

Re: OpenSSL 1.1.0 support

[Dirkjan Bussink]

Hi Willy,

> On 26 Oct 2016, at 11:40, Willy Tarreau  wrote:
> 
> Yes I'd rather have it work with 0.9.8 as it's still supported and used by
> some LTS distros. For example, RHEL5's regular support is due till March 2017
> and extended support till november 2020. It's not very likely that such users
> will decide to upgrade to 1.7 now especially since some of the SSL-related
> features only work with newer versions. But if we can make it work as it used
> to with limited effort it's better. Is your current patch capable of 
> supporting
> 0.9.8 ?

I don't think there's a reason it couldn't work. I haven't tested it though 
yet, only against 1.0.1 and 1.1.0 at this point. 

> Yes definitely. Also your new patch is much more readable and will make it
> easier to drop older versions in the future, I like it. I'll ping Emeric
> again since we got no response (ie I'll yell in the office) :-)

Alright, hopefully it's not too complicated to get this in then. 

Cheers,

Dirkjan

Re: OpenSSL 1.1.0 support

[Willy Tarreau]

Hi Dirkjan,

sorry for the delay.

On Sat, Sep 17, 2016 at 10:56:13PM +0200, Dirkjan Bussink wrote:
> I've gone for a somewhat different approach in this patch with a
> compatibility header file. It defines some inline functions from 1.1.0 when
> they are not available. Right now it implements the minimal things that
> HAProxy needs, so they aren't full replacements of what OpenSSL 1.1.0 would
> provide.

I definitely like this approach, and to be clear I want it merged before
1.7 release.

> It's in a separate header file, was not sure if this was something that
> should go in include/proto/ssl_sock.h then. Also brings up the question what
> the minimum version of OpenSSL is that is supported? A lot of the functions
> used are already available in 1.0.0 (which is already EOL), so not sure if
> the compatibility code is needed for 0.9.8 then?

Yes I'd rather have it work with 0.9.8 as it's still supported and used by
some LTS distros. For example, RHEL5's regular support is due till March 2017
and extended support till november 2020. It's not very likely that such users
will decide to upgrade to 1.7 now especially since some of the SSL-related
features only work with newer versions. But if we can make it work as it used
to with limited effort it's better. Is your current patch capable of supporting
0.9.8 ?

> Is this more the approach you were thinking about?

Yes definitely. Also your new patch is much more readable and will make it
easier to drop older versions in the future, I like it. I'll ping Emeric
again since we got no response (ie I'll yell in the office) :-)

Thanks!
Willy

Re: OpenSSL 1.1.0 support

[Dirkjan Bussink]

Hi Willy,


> On 29 Aug 2016, at 15:15, Willy Tarreau  wrote:
> 
> Hi Dirkjan,
> 
> CCing Emeric who will know better than me how to respond, but I have some
> questions at the end.

I've gone for a somewhat different approach in this patch with a compatibility 
header file. It defines some inline functions from 1.1.0 when they are not 
available. Right now it implements the minimal things that HAProxy needs, so 
they aren't full replacements of what OpenSSL 1.1.0 would provide.

It's in a separate header file, was not sure if this was something that should 
go in include/proto/ssl_sock.h then. Also brings up the question what the 
minimum version of OpenSSL is that is supported? A lot of the functions used 
are already available in 1.0.0 (which is already EOL), so not sure if the 
compatibility code is needed for 0.9.8 then?

Is this more the approach you were thinking about?

Cheers,

Dirkjan



0001-Add-support-for-OpenSSL-1.1.0.patch
Description: Binary data

Re: OpenSSL 1.1.0 support

[Willy Tarreau]

Hi Dirkjan,

CCing Emeric who will know better than me how to respond, but I have some
questions at the end.

On Mon, Aug 29, 2016 at 02:22:23PM +0200, Dirkjan Bussink wrote:
> Hi all,
> 
> I've attached a patch for support for OpenSSL 1.1.0. That version changes 
> quite a few things, mostly it makes a lot of the structures now opaque and 
> private and provides functions to interact with them. Most of this change 
> consists of using these new functions on OpenSSL 1.1.0 and newer.
> 
> There are a few things worth calling out specifically in this patch:
> 
> - I was not 100% clear on the handshake logic. It looked like it tried to 
> detect if a handshake was ever attempted and distinguish that from a failure 
> case. I've used the new state mechanism available through SSL_get_state to 
> hopefully mimic similar behavior. I might have gotten this totally wrong 
> though.
> - The Makefile change was needed so that linking the OpenSSL bits also pulls 
> in dl if needed (OpenSSL uses this itself). Also OpenSSL will now use pthread 
> by default, so maybe that also should be added? Although I've used 
> USE_PTHREAD_PSHARED for now in testing to link that.
> - The code guarded with #ifdef SSL_CTX_get_tlsext_status_arg ideally would 
> also use that macro, but there seems to be a closing brace missing at 
> https://github.com/openssl/openssl/blob/fddfc0afc84728f8a5140685163e66ce6471742d/include/openssl/tls1.h#L300-L301
>  so it throws an error. That's why I've used the implementation of that macro 
> in the code instead.
> 
> What this does not address at the moment is fixing the use of deprecated 
> functions. These are the warnings still present with these changes:
> 
> [jessie-amd64]  src/ssl_sock.c: In function 'ssl_tlsext_ticket_key_cb':
> [jessie-amd64]  src/ssl_sock.c:492:3: warning: 'RAND_pseudo_bytes' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/rand.h:47)
>  [-Wdeprecated-declarations]
> [jessie-amd64] if(!RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH))
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c: In function 'ssl_sock_prepare_ctx':
> [jessie-amd64]  src/ssl_sock.c:2731:3: warning: 'TLSv1_server_method' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/ssl.h:1597)
>  [-Wdeprecated-declarations]
> [jessie-amd64] SSL_CTX_set_ssl_version(ctx, TLSv1_server_method());
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c:2734:3: warning: 'TLSv1_1_server_method' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/ssl.h:1603)
>  [-Wdeprecated-declarations]
> [jessie-amd64] SSL_CTX_set_ssl_version(ctx, TLSv1_1_server_method());
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c:2738:3: warning: 'TLSv1_2_server_method' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/ssl.h:1609)
>  [-Wdeprecated-declarations]
> [jessie-amd64] SSL_CTX_set_ssl_version(ctx, TLSv1_2_server_method());
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c:2824:13: warning: assignment discards 'const' 
> qualifier from pointer target type
> [jessie-amd64]cipher = sk_SSL_CIPHER_value(ciphers, idx);
> [jessie-amd64]   ^
> [jessie-amd64]  src/ssl_sock.c: In function 'ssl_sock_prepare_srv_ctx':
> [jessie-amd64]  src/ssl_sock.c:3111:3: warning: 'TLSv1_client_method' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/ssl.h:1598)
>  [-Wdeprecated-declarations]
> [jessie-amd64] SSL_CTX_set_ssl_version(srv->ssl_ctx.ctx, 
> TLSv1_client_method());
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c:3114:3: warning: 'TLSv1_1_client_method' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/ssl.h:1604)
>  [-Wdeprecated-declarations]
> [jessie-amd64] SSL_CTX_set_ssl_version(srv->ssl_ctx.ctx, 
> TLSv1_1_client_method());
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c:3118:3: warning: 'TLSv1_2_client_method' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/ssl.h:1610)
>  [-Wdeprecated-declarations]
> [jessie-amd64] SSL_CTX_set_ssl_version(srv->ssl_ctx.ctx, 
> TLSv1_2_client_method());
> [jessie-amd64] ^
> [jessie-amd64]  src/ssl_sock.c: In function '__ssl_sock_deinit':
> [jessie-amd64]  src/ssl_sock.c:6254:9: warning: 'ERR_remove_state' is 
> deprecated (declared at 
> /data/build/jessie-amd64/packages/haproxy/tmp-install/openssl-static/include/openssl/err.h:247)
>  [-Wdeprecated-declarations]
> [jessie-amd64]   ERR_remove_state(0);
> [jessie-amd64]  
> 
> 
> Let me know what you all think.


Since the API experienced a major change and causes a lot of #ifdefs,
what do you think about