On 05/17/21 21:19, Chapman Flack wrote:
> This makes twice in a row that I've failed to see how.
>
> If you go through the entries, in order, and simply prune from the list
> the ones you can already prove would never apply to this connection, how
> does that break the ordering principle?
Ok, I see how what I proposed looks out-of-order just in that it lets the
initial TLS negotiation be influenced by the minimum version over all
potentially-applicable entries.
But that's just an optimization anyway. The same ultimate effect would be
achieved by unconditionally allowing anything back to TLSv1 to be negotiated
at SSLRequest time, and then (processing the entries in order as always)
rejecting the connection if the first one that could apply expects a higher
protocol version.
The pre-scan and use of the minimum version encountered has only the effect
of fast-failing a TLS negotiation for a version that won't possibly succeed.
Regards,
-Chap
