<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Emilia,<div class=""><br class=""></div><div class="">I was able to test the patch and it does successfully now allow the server to fall back to a Certificate message if it does not accept the SessionTicket sent by the client.</div><div class=""><br class=""></div><div class=""> Thanks for your help,</div><div class=""> Erik</div><div class=""><br class="">
<br class=""><div><div class="">On 27 Mar2015, at 12:33, Emilia Käsper <<a href="mailto:emilia@openssl.org" class="">emilia@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">John, Erik,<div class=""><br class=""></div><div class=""><a href="https://github.com/openssl/openssl/pull/250" class="">https://github.com/openssl/openssl/pull/250</a><br class=""></div><div class=""><br class=""></div><div class="">Can you verify whether this resolves the problem? (And also, does not create any new problems.)</div><div class=""><br class=""></div><div class="">Note this is pending team review so is not a definitive fix. But since we're maintaining this feature more or less blind, we'd appreciate your help testing the fix.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Emilia</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Mar 26, 2015 at 9:02 PM, John Foley <span dir="ltr" class=""><<a href="mailto:foleyj@cisco.com" target="_blank" class="">foleyj@cisco.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class="">
Someone that understands EAP better than myself should probably
provide input. But my limited understand of EAP-FAST is it
contributes to the master secret calculation used for the TLS
session. See section RFC 4851 Section 5.1. My understanding is this
logic applies to both new and resumed sessions. Hence,
tls_session_secret_cb() is always in play for EAP-FAST.<div class=""><div class="h5"><br class="">
<br class="">
<br class="">
<div class="">On 03/26/2015 02:13 PM, Emilia Käsper
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class=""><br class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Tue, Mar 24, 2015 at 2:01 PM, John
Foley <span dir="ltr" class=""><<a href="mailto:foleyj@cisco.com" target="_blank" class="">foleyj@cisco.com</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class=""> Trying again w/o
PGP... :-)<br class="">
<br class="">
Thanks for taking a look at this problem. Regarding how
to handle a failure in the session secret callback, the
legacy logic would likely result in a "bad record mac"
error because the master secrets on the client/server do
not match.</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">But only in case we are actually resuming - no? Does
the client always have a PAC available - I would guess
not? Seems the legacy logic is such that it "happens to
work", but I'd like to clear it up.</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF" class=""> It would be good
to trigger an internal error to aid with
troubleshooting. Maybe something like:<br class="">
<br class="">
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,
ERR_R_INTERNAL_ERROR);<br class="">
goto err;<br class="">
<br class="">
It's debatable whether the alert needs to be sent to the
server. Since this is an internal error, it should be
safe to send the alert. Therefore, maybe you would
actually want to do something like:<br class="">
<br class="">
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,
ERR_R_INTERNAL_ERROR);<br class="">
al = SSL_AD_INTERNAL_ERROR;<br class="">
goto f_err;
<div class="">
<div class=""><br class="">
<br class="">
<br class="">
<br class="">
<div class="">On 03/23/2015 09:17 PM, Emilia Käsper wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class=""><br class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Tue, Mar 24, 2015
at 1:20 AM, John Foley (foleyj) <span dir="ltr" class=""><<a href="mailto:foleyj@cisco.com" target="_blank" class="">foleyj@cisco.com</a>></span>
wrote:<br class="">
<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 class="">
<br class="">
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 class="">
<br class="">
<br class="">
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 class="">
<br class="">
if (s->version >= TLS1_VERSION
&& s->tls_session_secret_cb) {<br class="">
SSL_CIPHER *pref_cipher = NULL;<br class="">
s->session->master_key_length =
sizeof(s->session->master_key);<br class="">
if (s->tls_session_secret_cb(s,
s->session->master_key,<br class="">
&s->session->master_key_length,<br class="">
NULL,
&pref_cipher,<br class="">
s->tls_session_secret_cb_arg)) {<br class="">
s->session->cipher =
pref_cipher ?<br class="">
pref_cipher :
ssl_get_cipher_by_char(s, p + j);<br class="">
s->hit = 1;<br class="">
}<br class="">
}<br class="">
<br class="">
Why does the client-side now assume the
server is doing session resumption simply
because the session secret callback
facility is being used?<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">
<pre style="word-wrap: break-word; white-space: pre-wrap;" class="">#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" class=""><font face="arial, sans-serif" class=""><span style="white-space:normal" class="">This is surely wrong as it's just ignoring the failure?</span></font></pre>
<pre style="word-wrap:break-word" class=""><font face="arial, sans-serif" class=""><span style="white-space:normal" class="">Thanks,</span></font></pre>
<pre style="word-wrap:break-word" class=""><font face="arial, sans-serif" class=""><span style="white-space:normal" class="">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 class="">
From: openssl-dev [<a href="mailto:openssl-dev-bounces@openssl.org" target="_blank" class="">openssl-dev-bounces@openssl.org</a>]
on behalf of Dr. Stephen Henson [<a href="mailto:steve@openssl.org" target="_blank" class="">steve@openssl.org</a>]<br class="">
Sent: Thursday, March 19, 2015 11:49 AM<br class="">
To: <a href="mailto:openssl-dev@openssl.org" target="_blank" class="">openssl-dev@openssl.org</a><br class="">
Subject: Re: [openssl-dev] s3_clnt.c
changes regarding external pre-shared
secret seem to break EAP-FAST<br class="">
<div class="">
<div class=""><br class="">
On Thu, Mar 19, 2015, Erik Tkal wrote:<br class="">
<br class="">
><br class="">
> If I do not send a sessionID in
the clientHello but do send a valid<br class="">
> sessionTicket extension, the
server goes straight to
changeCipherSpec and<br class="">
> the client generates an
UnexpectedMessage alert.<br class="">
><br class="">
<br class="">
Does the server send back an empty
session ticket extension?<br class="">
<br class="">
Steve.<br class="">
--<br class="">
Dr Stephen N. Henson. OpenSSL project
core developer.<br class="">
Commercial tech support now available
see: <a href="http://www.openssl.org/" target="_blank" class="">http://www.openssl.org</a><br class="">
_______________________________________________<br class="">
openssl-dev mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class="">
_______________________________________________<br class="">
openssl-dev mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br class="">
<fieldset class=""></fieldset>
<br class="">
<pre class="">_______________________________________________
openssl-dev mailing list
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
</blockquote>
<br class="">
</div>
</div>
</div>
<br class="">
_______________________________________________<br class="">
openssl-dev mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br class="">
</div></div></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">openssl-dev mailing list<br class="">To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" class="">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class=""></div></div><br class=""></div></body></html>