<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="">FWIW, RFC 5077 says:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always;"><span class="h3" style="line-height: 0pt; display: inline; font-size: 1em; font-weight: bold;"><h3 style="line-height: 0pt; display: inline; font-size: 1em;" class=""><a class="selflink" name="section-3.4" href="https://tools.ietf.org/html/rfc5077#section-3.4" style="color: black; text-decoration: none;">3.4</a>. Interaction with TLS Session ID</h3></span>
...</pre><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always;">
When presenting a ticket, the client MAY generate and include a
Session ID in the TLS ClientHello. If the server accepts the ticket
and the Session ID is not empty, then it MUST respond with the same
Session ID present in the ClientHello. This allows the client to
easily differentiate when the server is resuming a session from when
it is falling back to a full handshake. Since the client generates a
Session ID, the server MUST NOT rely upon the Session ID having a
particular value when validating the ticket. If a ticket is
presented by the client, the server MUST NOT attempt to use the
Session ID in the ClientHello for stateful session resumption.
<b class="">Alternatively, the client MAY include an empty Session ID in the
ClientHello. In this case, the client ignores the Session ID sent in
the ServerHello and determines if the server is resuming a session by
the subsequent handshake messages.</b>
</pre></div><div class="">If I do not send a sessionID in the clientHello but do send a valid sessionTicket extension, the server goes straight to changeCipherSpec and the client generates an UnexpectedMessage alert.</div><div class=""><br class=""></div><div class="">This is slightly different from the issue I saw before, as I was trying to use stock OpenSSL instead of our application to recreate by making minor changes. In this case I was *not* setting the session secret callback but instead using OpenSSL’s default mechanism and only removing the sessionId from the client. In the full case using EAP-FAST I’ll have to wire up session secret processing and the sessionTicket extension handling on both sides, but this shows something is definitely awry with the recent changes.</div><div class=""><br class=""></div><div class=""> Erik</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">write to 0x7fafcac26c60 [0x7fafcc004603] (467 bytes => 467 (0x1D3))</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 16 03 01 01 ce 01 00 01-ca 03 03 a5 20 37 c1 48 ............ 7.H</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0010 - 64 46 12 0a d0 1c 70 a8-28 7b 05 51 f0 14 31 7b dF....p.({.Q..1{</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0020 - 1c fe 52 c2 9c 37 74 d9-a9 17 57 00 00 94 c0 30 ..R..7t...W....0</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...*</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 .@.3.2.....E.D.1</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A............</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">00b0 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">00c0 - 00 ff 01 00 01 0d 00 0b-00 04 03 00 01 02 00 0a ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">00d0 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2............</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">00e0 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">00f0 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0100 - 00 0f 00 10 00 11 00 23-00 a0 d7 39 e6 23 d8 a1 .......#...9.#..</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0110 - 41 bd a1 1a 55 4d 7f 07-6d 4d 1c 89 b0 f8 1d b4 A...UM..mM......</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0120 - 15 a0 e4 96 73 6a 75 53-a3 0d d3 90 2a 48 92 ec ....sjuS....*H..</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0130 - be 57 15 fe 20 c3 0f 34-12 63 e9 87 d6 87 06 d1 .W.. ..4.c......</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0140 - f2 28 5e 3e 7d 6c 96 79-f9 6d 76 27 51 07 fc a3 .(^>}l.y.mv'Q...</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0150 - 16 83 64 e1 af 24 03 b0-34 c4 d1 a3 f9 2e f8 75 ..d..$..4......u</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0160 - 30 18 27 55 54 3c 53 9a-70 1a cc 97 95 b7 a1 09 0.'UT<S.p.......</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0170 - 02 ac ca fd 6d 17 21 fe-c4 22 b9 99 d5 f2 91 73 ....m.!..".....s</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0180 - 85 b3 55 89 78 0d d3 c0-7e b6 a2 54 c3 d6 f6 f1 ..U.x...~..T....</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0190 - 18 d5 4c 78 00 d4 61 ad-1e a8 68 e4 4b 6c 0d b0 ..Lx..a...h.Kl..</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">01a0 - 45 4c 33 a2 08 ca 2f 03-e2 ab 00 0d 00 20 00 1e EL3.../...... ..</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">01b0 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">01c0 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f ................</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">01d0 - 00 01 01 ...</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5))</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 16 03 03 00 36 ....6</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">read from 0x7fafcac26c60 [0x7fafcc000008] (54 bytes => 54 (0x36))</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 02 00 00 32 03 03 89 9d-07 82 8f 74 e7 dd 44 6e ...2.......t..Dn</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0010 - 16 28 c9 15 f2 5c d5 5b-f8 70 03 c2 48 f6 1a b4 .(...\.[.p..H...</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0020 - 54 d5 1f af ca 09 00 c0-30 00 00 0a ff 01 00 01 T.......0.......</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0030 - 00 00 0f 00 01 01 ......</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">TLS server extension "renegotiation info" (id=65281), len=1</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0001 - <SPACES/NULS></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">TLS server extension "heartbeat" (id=15), len=1</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 01 .</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5))</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 14 03 03 00 01 .....</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">read from 0x7fafcac26c60 [0x7fafcc000008] (1 bytes => 1 (0x1))</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 01 .</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">write to 0x7fafcac26c60 [0x7fafcc801000] (7 bytes => 7 (0x7))</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">0000 - 15 03 03 00 02 02 0a .......</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">140735260517200:error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early:s3_pkt.c:1340:</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">---</div></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 17 Mar 2015, at 4:16 PM, Erik Tkal <<a href="mailto:etksubs@GMAIL.COM" class="">etksubs@GMAIL.COM</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=""><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 class=""><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=""></div></div></blockquote></div><br class=""></body></html>