[openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[John Foley]

Something does seem suspect here.  Maybe I'm misusing the API, but when
using the attached patch for s_server, the client side does reject the
NewSessionTicket message from the server.  This only happens when using
SSL_set_session_secret_cb() on the server side.  When using this
callback facility, the server changes the order of the handshake messages. 

The order without using SSL_set_session_secret_cb() is:

<-ServerHello
<-Certificate
<-ServerKeyExchange
<-ServerHelloDone
->ClientKeyExchange
->ChangeCipherSpec
<-NewSessionTicket
<-ChangeCipherSpec


The order when using SSL_set_session_secret_cb() is:

<-ServerHello
<-NewSessionTicket
<-ChangeCipherSpec
->Alert


The session ticket extension in the ClientHello is empty in both cases. 
It appears the server thinks it's using a valid session ticket and
proceeds directly to the ChangeCipherSpec.



On 03/17/2015 04:16 PM, Erik Tkal 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
>>>
>>> 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
>>>
>>> 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
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150318/5dd07ab4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recreate.patch
Type: text/x-patch
Size: 1989 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150318/5dd07ab4/attachment-0001.bin>