<div dir="ltr">Hi!<br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-13 23:27 GMT+02:00 Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span>:<div class="im">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hello!<div><br></div><div>Recently after upgrading to newer openssl our server started to suggest ECC cipher suites.</div><div>Most of clients work fine, but there is at least one which does not — WebDAV client in OmniPlan application under MacOS 10.9.</div>



<div><br></div><div>This application makes three connections to check 
connectivity. First two of them fail with "error: bad record mac" or 
sometimes badarg in erlang:size([22,3,1,0,158,1,0,0,154,3,1,83,74|...]) at tls_record.erl:122.</div>


<div>Third connection always fail with {case_clause,{4}} 
in ssl_v3:mac_hash because it is negotiated as SSLv3 with SHA256 hash 
which is not described in RFC and thus not supported in Erlang.</div><div><br></div><div>I
 tried to examine SSL code to understand how that could be true (didn't 
succeed so far), tried to replay third connection client_hello (server 
replies with very different server_hello), finally I've written a tool 
to dump traffic.</div>


<div><br></div><div>So, using <a href="https://github.com/stolen/ssldump" target="_blank">https://github.com/stolen/ssldump</a>
 I've collected this log showing the three connections from weird client
 to simple SSL server (listen — transport_accept — ssl_accept — die) 
leading to erroneous negotiation: <a href="http://pastebin.com/Ym7na7mi" target="_blank">http://pastebin.com/Ym7na7mi</a></div>


<div><br></div><div><br></div><div>Currently I've found workaround — 
disabling ECC cipher suites with hashes other than MD5 and SHA, but I 
think it may be possible to behave better allowing even this client to 
work.</div>


<div><br></div><div>So, there are two bugs:</div><div>  * Somewhere packet is received as list instead of binary leading to badarg in erlang:size</div></div></blockquote><div><br> </div></div><div> We will look into it, do you have a easy way to reproduce it?<br>

<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>  * At some conditions it is possible to negotiate SSLv3 with SHA256 and then crash server worker at encoding message.</div>



<div><br></div></div></blockquote><div><br></div></div><div>This sounds like a  bug fixed in the latest version of the ssl application (ssl-5.3.4 released in 17.0)<br><br><li>
          <p>
            "Fix possible mismatch between SSL/TLS version and default
            ciphers. Could happen when you specified SSL/TLS-version
            in optionlist to listen or accept.</p></li><li><p>Own Id: OTP-11712"</p></li><br></div><div>Have you tried this version?<br></div><div> </div><br></div></div><div class="gmail_extra">Regards Ingela Erlang/OTP team - Ericsson AB</div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><br></div><br></div></div>