<div dir="ltr">Hi!<br><div class="gmail_extra"><br><h3 style="font-size:medium;font-weight:normal;margin:0px;padding-top:0px;padding-right:0px;padding-left:0px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;font-family:arial,sans-serif">
<span style="font-family:arial;font-size:small">We are currently focusing on gracefulness an running </span> <a href="http://www.codenomicon.com/" target="_blank" style="color:rgb(102,0,153);text-decoration:none"><span style="font-weight:bold">Codenomicon</span><font color="#660099"> Defensics</font></a> <span style="font-family:arial;font-size:small">tests.If we find any problems they will be fixed promptly. </span></h3>
<h3 style="font-size:medium;font-weight:normal;margin:0px;padding-top:0px;padding-right:0px;padding-left:0px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;font-family:arial,sans-serif"><span style="font-family:arial;font-size:small"><br>
</span></h3><h3 style="font-size:medium;font-weight:normal;margin:0px;padding-top:0px;padding-right:0px;padding-left:0px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;font-family:arial,sans-serif"><span style="font-family:arial;font-size:small">In the upcoming release we have for instance added a format functions for state data so that secrets should not be visible in crash-reports. Even</span><br>
</h3><div><span style="font-family:arial;font-size:small">if this is not as bad as heart-bleed. </span></div><div><span style="font-family:arial;font-size:small"><br></span></div><div><span style="font-family:arial;font-size:small">See also comments below.</span></div>
<div><span style="font-family:arial;font-size:small"><br></span></div><div class="gmail_quote">2014-06-06 11:14 GMT+02:00 Andreas Schultz <span dir="ltr"><<a href="mailto:aschultz@tpip.net" target="_blank">aschultz@tpip.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<div><br>
----- Original Message -----<br>
> I'd be glad if Erlang core team could give an idea about how the<br>
> vulnerability of CVE-2014-0224 would or would not affect Erlang ssl<br>
> module:<br>
><br>
> <a href="http://www.openssl.org/news/secadv_20140605.txt" target="_blank">http://www.openssl.org/news/secadv_20140605.txt</a><br>
> <a href="http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html" target="_blank">http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html</a><br>
<br>
</div>My take on this:<br>
<br>
Short version<br>
=============<br>
<br>
I believe that Erlang SSL does not handle out of sequence CCS (Change-Cipher-Spec)<br>
messages correctly, whether that can be exploited or not is unclear.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Long version<br>
============<br>
<br>
>From reading the source, I would say that the SSL application will accept<br>
CCS messages that are out of sequence.<br>
<br>
tls_connection:next_state is processing the packets. Normal handshake records<br>
are processed through the tls_connection FSM, but a CCS message is processed<br>
immediately, outside of the FSM in any state.<br></blockquote><div><span style="white-space:nowrap"><br></span></div><div><span style="white-space:nowrap">Yes this is done as data received after the CSS shall be decoded using the new connection state, however</span><br>
</div><div><h3 style="font-size:medium;font-weight:normal;margin:0px;padding-top:0px;padding-right:0px;padding-left:0px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;font-family:arial,sans-serif"><span style="font-family:arial;font-size:small">we are state aware, and I will add a state check and a flag to check that the next messages is finished (or protocol_next_negotion and finished),</span></h3>
</div><div>we should not take any unnecessary risks with security.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
One of the problems OpenSSL has with this, are that invalid pointers might be<br>
exploited. Luckily this is not going to be an issue for Erlang, ssl might crash,<br>
but it will not reveal sensitive data.<br>
<br></blockquote><div><br></div><div>That is one of the upsides having the code in Erlang instead of C/C++ :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The other issue as described by OpenSSL:<br>
<br>
> An attacker using a carefully crafted handshake can force the use of weak<br>
> keying material in OpenSSL SSL/TLS clients and servers. This can be exploited<br>
> by a Man-in-the-middle (MITM) attack where the attacker can decrypt and<br>
> modify traffic from the attacked client and server.<br>
<br>
Now this might be a problem for Erlang. A CCS will activate the pending connection<br>
state. ssl_record initializes the pending states with values that are partly valid.<br>
The bulk_cipher_algo and the secrets are not initialized, so I'm not sure if it<br>
would be possible to craft the handshake sequence in a way to have valid, but weak<br>
values in there.<br>
<br></blockquote><div> </div><div>Does this not require that you can tamper both with the client and the server? </div><div><br></div><div>Regards Ingela Erlang/OTP Team - Ericsson AB</div><div><br></div><div> <br></div>
</div></div></div>