> On Sep 11, 2018, at 12:33 PM, Jordan Brown <open...@jordan.maileater.net>
> wrote:
>
> Thanks!
>
> Now I need to wrap my head around what that all means.
>
> It sounds like the protocol doesn't really have a version-independent way for
> the version negotiation to cleanly fail. That's unfortunate.
Well, once SSL3 is out of the picture (as in OpenSSL 1.1.x), TLS 1.0 and up
do all support the requisite alert, and the 1.1.x state machine seems to
handle this more along the lines that you expect. The issue is that 1.0.2
is older and tries to stick to SSL 3.0 capabilities when talking to SSL 3.0
clients, ... so things get a bit messier.
Part of the confusion is also using a version inflexible method on the
client, that's rarely done. Instead of "s_client -tls1" it is wiser
to test with "s_client -no_ssl2 -no_ssl3 -no_tls1_1 -no_tls1_2". That
is subtract the versions you don't want. IIRC that still leaves you
"version flexible" even if only with a single version.
In OpenSSL 1.1.x all the "-no_some_version" options are superseded
by the min/max version options, which should be used instead.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
