<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I don’t disagree, but I’m looking for independent confirmation that the changes are not correct. They do not appear to specifically have been made for any vulnerabilities.</div><div class=""><br class=""></div><div class="">In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client. With the first change I noted below the possession of a tls_session_secret now implies by the setting of s->hit on the client that the session *will* be resumed, which is not the case. The resumption requires determination of the next message. In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension.</div><div class=""><br class=""></div><div class=""> Erik</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan <<a href="mailto:karthikeyan.bhargavan@inria.fr" class="">karthikeyan.bhargavan@inria.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I would be very careful about this code. When we ran our tests on OpenSSL (<a href="http://www.smacktls.com/" class="">www.smacktls.com</a>), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). <div class=""><br class=""></div><div class="">Let’s carefully test any change here, so we do not re-enable <span style="white-space: pre-wrap; widows: 1;" class="">CVE-2014-0224 (Early CCS Attack)</span><div class=""><br class=""></div><div class=""><br class=""><div class=""><div class="">On 17 Mar 2015, at 18:53, Erik Tkal <<a href="mailto:etksubs@gmail.com" class="">etksubs@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session.</div><div class=""><br class=""></div><div class="">RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message.</div><div class=""><br class=""></div><div class="">I traced this to the following change:</div><div class=""><br class=""></div><div class=""><div class=""> Set s->hit when resuming from external pre-shared secret.</div><div class=""><br class=""></div> <a href="https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9" class="">https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9</a></div><div class=""><br class=""></div><div class="">When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s->hit, which then “requires* that a finished message is expected next, triggering the alert otherwise.</div><div class=""><br class=""></div><div class="">Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point:</div><div class=""><br class=""></div><div class=""> Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset</div><div class=""><br class=""></div><div class=""> <a href="https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43" class="">https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43</a></div><div class=""><br class=""></div><div class="">In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec.</div><div class=""><br class=""></div><div class=""> Thanks,</div><div class=""> Erik</div><div class=""><br class=""></div><div apple-content-edited="true" class=""><div class="" style="font-family: Arial; orphans: 2; text-align: -webkit-auto; widows: 2;"><span class="Apple-style-span" style="font-family: Arial, sans-serif; font-size: 13px;">....................................</span></div><div class="" style="font-family: Arial; orphans: 2; text-align: -webkit-auto; widows: 2;">Erik Tkal</div><div class="" style="font-family: Arial; orphans: 2; text-align: -webkit-auto; widows: 2;"><a href="mailto:etkal@cisco.com" class="">etkal@cisco.com</a></div><div class="" style="font-family: Arial; orphans: 2; text-align: -webkit-auto; widows: 2;"><br class=""></div></div></div>_______________________________________________<br class="">openssl-dev mailing list<br class="">To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class=""></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">openssl-dev mailing list<br class="">To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class=""></div></blockquote></div><br class=""></body></html>