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
et...@cisco.com <mailto:et...@cisco.com>
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
