> Le 23 mars 2017 à 12:25, Willy Tarreau <[email protected]> a écrit : > > On Thu, Mar 23, 2017 at 11:26:50AM +0100, Emmanuel Hocdet wrote: >> Emeric's suggestion is not on the ML. > > I transcripted it in the other e-mail of this same thread. > >> If no- and force- are defined as deprecated it can make a difference. >> I'm not used to seeing this kind of proposal for haproxy configuration ;-) > > The purpose is not to deprecate them but to "emulate" them and only > to deprecate those causing trouble. > Ok, this is what I propose.
>> (for the hole, openssl low leveling the range: no-tlsv1.1 become >> max-tlsv1.0) > > Here for me, no-tlsv1.1 alone would be rejected because it's ambigous as it > either means max-tlsv1.0 or min-tlsv1.2. However if you have : > I agree, haproxy should, at least, warm in this case. It’s in my todo, waiting for more feedback on my patches. > no-sslv3 no-tlsv1.0 no-tlsv1.1 > > Then there's no ambiguity, only tlsv1.2 remains. Conversely : > > no-tlsv1.1 no-tlsv1.2 > > Restricts us to sslv3 and tlsv1.0. > > So in fact we know the bounds we support and we convert a contigous range > into a min+max. Discontinuities are rejected and it should not be a problem. > Emeric told me that he knows some deployments where people rejected recent > versions due to interoperability issues, but there's no reason for blocking > only a middle version and not either older or newer ones. > Yep, perhaps continue to discuss in the treads with my patches. > I know Emeric is busy at the moment so I don't expect him to read this > thread yet :-) > Manu
