<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) <span dir="ltr"><<a href="mailto:foleyj@cisco.com" target="_blank">foleyj@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We've found a way to recreate the scenario using s_client/s_server.  We're using the -no_ticket option on the server.  Therefore, the ServerHello doesn't contain the session ticket extension.  It also doesn't send the NewSessionTicket message.<br>
<br>
To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption.  This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message.  The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state.<br>
<br>
<br>
As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code:<br>
<br>
    if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) {<br>
        SSL_CIPHER *pref_cipher = NULL;<br>
        s->session->master_key_length = sizeof(s->session->master_key);<br>
        if (s->tls_session_secret_cb(s, s->session->master_key,<br>
                                     &s->session->master_key_length,<br>
                                     NULL, &pref_cipher,<br>
                                     s->tls_session_secret_cb_arg)) {<br>
            s->session->cipher = pref_cipher ?<br>
                pref_cipher : ssl_get_cipher_by_char(s, p + j);<br>
            s->hit = 1;<br>
        }<br>
    }<br>
<br>
Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used?<br></blockquote><div><br></div><div>Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch.</div><div><br></div><div>While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this</div><div><br></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">#ifndef OPENSSL_NO_TLSEXT
        /* check if we want to resume the session based on external pre-shared secret */
        if (s->version >= TLS1_VERSION && s->tls_session_secret_cb)
                {
                SSL_CIPHER *pref_cipher=NULL;
                s->session->master_key_length=sizeof(s->session->master_key);
                if (s->tls_session_secret_cb(s, s->session->master_key,
                                             &s->session->master_key_length,
                                             NULL, &pref_cipher,
                                             s->tls_session_secret_cb_arg))
                        {
                        s->session->cipher = pref_cipher ?
                                pref_cipher : ssl_get_cipher_by_char(s, p+j);
                        }
                }
#endif /* OPENSSL_NO_TLSEXT */</pre><pre style="word-wrap:break-word"><font face="arial, sans-serif"><span style="white-space:normal">This is surely wrong as it's just ignoring the failure?</span></font></pre><pre style="word-wrap:break-word"><font face="arial, sans-serif"><span style="white-space:normal">Thanks,</span></font></pre><pre style="word-wrap:break-word"><font face="arial, sans-serif"><span style="white-space:normal">Emilia</span></font></pre></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
________________________________________<br>
From: openssl-dev [<a href="mailto:openssl-dev-bounces@openssl.org">openssl-dev-bounces@openssl.org</a>] on behalf of Dr. Stephen Henson [<a href="mailto:steve@openssl.org">steve@openssl.org</a>]<br>
Sent: Thursday, March 19, 2015 11:49 AM<br>
To: <a href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a><br>
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST<br>
<div class=""><div class="h5"><br>
On Thu, Mar 19, 2015, Erik Tkal wrote:<br>
<br>
><br>
> If I do not send a sessionID in the clientHello but do send a valid<br>
> sessionTicket extension, the server goes straight to changeCipherSpec and<br>
> the client generates an UnexpectedMessage alert.<br>
><br>
<br>
Does the server send back an empty session ticket extension?<br>
<br>
Steve.<br>
--<br>
Dr Stephen N. Henson. OpenSSL project core developer.<br>
Commercial tech support now available see: <a href="http://www.openssl.org" target="_blank">http://www.openssl.org</a><br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</div></div></blockquote></div><br></div></div>