<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Something does seem suspect here. Maybe I'm misusing the API, but
when using the attached patch for s_server, the client side does
reject the NewSessionTicket message from the server. This only
happens when using SSL_set_session_secret_cb() on the server side.
When using this callback facility, the server changes the order of
the handshake messages. <br>
<br>
The order without using SSL_set_session_secret_cb() is:<br>
<br>
<-ServerHello<br>
<-Certificate<br>
<-ServerKeyExchange<br>
<-ServerHelloDone<br>
->ClientKeyExchange<br>
->ChangeCipherSpec<br>
<-NewSessionTicket<br>
<-ChangeCipherSpec<br>
<br>
<br>
The order when using SSL_set_session_secret_cb() is:<br>
<br>
<-ServerHello<br>
<-NewSessionTicket<br>
<-ChangeCipherSpec<br>
->Alert<br>
<br>
<br>
The session ticket extension in the ClientHello is empty in both
cases. It appears the server thinks it's using a valid session
ticket and proceeds directly to the ChangeCipherSpec.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/17/2015 04:16 PM, Erik Tkal
wrote:<br>
</div>
<blockquote
cite="mid:3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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 moz-do-not-send="true"
href="mailto:karthikeyan.bhargavan@inria.fr" class="">karthikeyan.bhargavan@inria.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div 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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:etksubs@gmail.com" class="">etksubs@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite" 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
openssl-dev mailing list
To unsubscribe: <a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>