<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/01/2016 18:43, Salz, Rich wrote:<br>
    </div>
    <blockquote class=" cite"
id="mid_b882239923384b5a9a2549163f2aa911_usma1ex_dag1mb1_msg_corp_akamai_com"
cite="mid:b882239923384b5a9a2549163f2aa911@usma1ex-dag1mb1.msg.corp.akamai.com"
      type="cite">
      <pre wrap="">Are you going to keep posting and posting until you get a response? :(

Master branch, 1.1, is not released but will not be vulnerable (may already be fixed)
1.0.2 is not vulnerable.
1.0.1f and later are not vulnerable.
1.0.0 might be, and is end of life anyway so you should move of that.
0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable.
</pre>
    </blockquote>
    <tt>If you read the description of SLOTH (linked in the OP), you <br>
      will see that it is not limited to TLS 1.2 and probably <br>
      affects the TLS/SSL versions implemented by older (end of <br>
      life) OpenSSL versions such as 0.9.8.</tt><tt><br>
    </tt><br>
    <tt>Basically, it is a laundry list of ways that backward <br>
      compatible hash uses in the SSL/TLS protocols are weaker <br>
      than some people assume.  Their summary list doesn't even <br>
      consider the possibility that some people still need to use <br>
      TLS 1.1 or older, so barely mentions those.<br>
      <br>
      This also means that completely protecting an <br>
      implementation against SLOTH is not possible without <br>
      breaking interoperability with implementations that <br>
      are not or cannot be updated to the latest protocol <br>
      versions and features (This happens to include some <br>
      widely deployed embedded operating systems).<br>
    </tt><br>
    <tt>Now it so happens that SLOTH also includes an attack on <br>
      implementation bugs that can be tricked into <br>
      using/accepting MD5-based signatures when they shouldn't. <br>
       That *particular* aspect of SLOTH was apparently fixed <br>
      in 1.0.1f and 1.0.2</tt><tt> .<br>
      <br>
      The entire discussion would have been easier if the SLOTH <br>
      team at INRIA had given specific names and CVE ids for <br>
      each of the issues in their report, such that one might say <br>
      "SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3: <br>
      hypothetical for now, can be fixed with a cipher string <br>
      setting, etc. etc."  But no such names exist.<br>
    </tt><br>
    <pre class="moz-signature" cols="72">Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
  </body>
</html>