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.
> (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 :
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.
I know Emeric is busy at the moment so I don't expect him to read this
thread yet :-)
Willy
