<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">On 9/11/2018 9:46 AM, Viktor Dukhovni

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org">Part

      of the confusion is also using a version inflexible method on the

      client, that's rarely done.</blockquote>

    <br>

    My test engineers like trying all the variations, including the ones

    nobody will ever use :-)<br>

    <br>

    <blockquote type="cite"

      cite="mid:17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org">

      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.

    </blockquote>

    <br>

    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.<br>

    <br>

    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".<br>

    <br>

    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.<br>

    <br>

    Thanks again.

    <pre class="moz-signature" cols="72">-- 

Jordan Brown, Oracle Solaris</pre>

  </body>

</html>