[openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST
Erik Tkal
etksubs at gmail.com
Thu Mar 19 15:40:57 UTC 2015
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 . at .3.2.....E.D.1
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 <etksubs at GMAIL.COM> 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 <karthikeyan.bhargavan at inria.fr <mailto:karthikeyan.bhargavan at inria.fr>> 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 <etksubs at gmail.com <mailto:etksubs at gmail.com>> 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
>>> etkal at cisco.com <mailto:etkal at cisco.com>
>>>
>>> _______________________________________________
>>> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150319/77f41936/attachment-0001.html>
More information about the openssl-dev
mailing list