> 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
