[openssl-users] Version negotiation failure failure?

[Jordan Brown]

On 9/11/2018 9:46 AM, Viktor Dukhovni wrote:
> Part of the confusion is also using a version inflexible method on the
> client, that's rarely done.

My test engineers like trying all the variations, including the ones
nobody will ever use :-)

> 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 the application that's causing me trouble now, we start with
SSLv23_method and then add SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, and in this
particular test case SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2.

But how we construct the client configuration won't matter.  The client
says "the highest I support is 1.0" and the server says (to itself) "the
lowest I support is 1.1; I don't even know how to say 'no' so I'm just
giving up".

The key piece that I was missing - I hadn't looked at and thought about
the protocol enough - was that there's no version-independent way for
the server to fail.  If the server supports only versions larger than
the client supports, it has no way to say "no".  If the positions are
reversed, the server counter-offers a version that the client then
rejects as too old.

Thanks again.

-- 
Jordan Brown, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180911/1ffa494e/attachment.html>