Re: Some compilation SSL errors/warnings on debian testing

[Emmanuel Hocdet]

Hi Willy, Le 15 mars 2017 à 12:41, Emmanuel Hocdet <m...@gandi.net> a écrit : Le 14 mars 2017 à 19:11, Willy Tarreau <w...@1wt.eu> 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:

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