FWIW, RFC 5077 says:
3.4 <https://tools.ietf.org/html/rfc5077#section-3.4>. Interaction with TLS Session ID ... 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. 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. 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. 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. Erik write to 0x7fafcac26c60 [0x7fafcc004603] (467 bytes => 467 (0x1D3)) 0000 - 16 03 01 01 ce 01 00 01-ca 03 03 a5 20 37 c1 48 ............ 7.H 0010 - 64 46 12 0a d0 1c 70 a8-28 7b 05 51 f0 14 31 7b dF....p.({.Q..1{ 0020 - 1c fe 52 c2 9c 37 74 d9-a9 17 57 00 00 94 c0 30 ..R..7t...W....0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k 0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...* 0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../ 0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g 0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 [email protected] 0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./ 0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A............ 00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................ 00b0 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 ................ 00c0 - 00 ff 01 00 01 0d 00 0b-00 04 03 00 01 02 00 0a ................ 00d0 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2............ 00e0 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 ................ 00f0 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 ................ 0100 - 00 0f 00 10 00 11 00 23-00 a0 d7 39 e6 23 d8 a1 .......#...9.#.. 0110 - 41 bd a1 1a 55 4d 7f 07-6d 4d 1c 89 b0 f8 1d b4 A...UM..mM...... 0120 - 15 a0 e4 96 73 6a 75 53-a3 0d d3 90 2a 48 92 ec ....sjuS....*H.. 0130 - be 57 15 fe 20 c3 0f 34-12 63 e9 87 d6 87 06 d1 .W.. ..4.c...... 0140 - f2 28 5e 3e 7d 6c 96 79-f9 6d 76 27 51 07 fc a3 .(^>}l.y.mv'Q... 0150 - 16 83 64 e1 af 24 03 b0-34 c4 d1 a3 f9 2e f8 75 ..d..$..4......u 0160 - 30 18 27 55 54 3c 53 9a-70 1a cc 97 95 b7 a1 09 0.'UT<S.p....... 0170 - 02 ac ca fd 6d 17 21 fe-c4 22 b9 99 d5 f2 91 73 ....m.!..".....s 0180 - 85 b3 55 89 78 0d d3 c0-7e b6 a2 54 c3 d6 f6 f1 ..U.x...~..T.... 0190 - 18 d5 4c 78 00 d4 61 ad-1e a8 68 e4 4b 6c 0d b0 ..Lx..a...h.Kl.. 01a0 - 45 4c 33 a2 08 ca 2f 03-e2 ab 00 0d 00 20 00 1e EL3.../...... .. 01b0 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 ................ 01c0 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f ................ 01d0 - 00 01 01 ... read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5)) 0000 - 16 03 03 00 36 ....6 read from 0x7fafcac26c60 [0x7fafcc000008] (54 bytes => 54 (0x36)) 0000 - 02 00 00 32 03 03 89 9d-07 82 8f 74 e7 dd 44 6e ...2.......t..Dn 0010 - 16 28 c9 15 f2 5c d5 5b-f8 70 03 c2 48 f6 1a b4 .(...\.[.p..H... 0020 - 54 d5 1f af ca 09 00 c0-30 00 00 0a ff 01 00 01 T.......0....... 0030 - 00 00 0f 00 01 01 ...... TLS server extension "renegotiation info" (id=65281), len=1 0001 - <SPACES/NULS> TLS server extension "heartbeat" (id=15), len=1 0000 - 01 . read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5)) 0000 - 14 03 03 00 01 ..... read from 0x7fafcac26c60 [0x7fafcc000008] (1 bytes => 1 (0x1)) 0000 - 01 . write to 0x7fafcac26c60 [0x7fafcc801000] (7 bytes => 7 (0x7)) 0000 - 15 03 03 00 02 02 0a ....... 140735260517200:error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early:s3_pkt.c:1340: --- > On 17 Mar 2015, at 4:16 PM, Erik Tkal <[email protected]> wrote: > > 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. > > 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. > > Erik > > >> On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> I would be very careful about this code. When we ran our tests on OpenSSL >> (www.smacktls.com <http://www.smacktls.com/>), 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). >> >> Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 >> (Early CCS Attack) >> >> >> On 17 Mar 2015, at 18:53, Erik Tkal <[email protected] >> <mailto:[email protected]>> wrote: >> >>> In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a >>> non-resumed EAP-FAST session. >>> >>> 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. >>> >>> I traced this to the following change: >>> >>> Set s->hit when resuming from external pre-shared secret. >>> >>> >>> https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 >>> >>> <https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9> >>> >>> 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. >>> >>> Also, another change is suspect in that the latest code no longer sets the >>> flag that a CCS is acceptable at that point: >>> >>> Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is >>> reset >>> >>> >>> https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 >>> >>> <https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43> >>> >>> 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. >>> >>> Thanks, >>> Erik >>> >>> .................................... >>> Erik Tkal >>> [email protected] <mailto:[email protected]> >>> >>> _______________________________________________ >>> openssl-dev mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>> <https://mta.openssl.org/mailman/listinfo/openssl-dev> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> <https://mta.openssl.org/mailman/listinfo/openssl-dev> >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
