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