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
