<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Trying again w/o PGP...  :-)<br>
    <br>
    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.  It would be good to trigger an
    internal error to aid with troubleshooting.  Maybe something like:<br>
    <br>
            SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);<br>
            goto err;<br>
    <br>
    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>
    <br>
            SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);<br>
            al = SSL_AD_INTERNAL_ERROR;<br>
            goto f_err;<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 03/23/2015 09:17 PM, Emilia Käsper
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAGZjfUa8Sen7S=ccqSSv1nGodNFMttZEnEyhC2UvD7N-EBvM6w@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <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
                moz-do-not-send="true" 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 moz-do-not-send="true"
                href="mailto:openssl-dev-bounces@openssl.org">openssl-dev-bounces@openssl.org</a>]
              on behalf of Dr. Stephen Henson [<a moz-do-not-send="true"
                href="mailto:steve@openssl.org">steve@openssl.org</a>]<br>
              Sent: Thursday, March 19, 2015 11:49 AM<br>
              To: <a moz-do-not-send="true"
                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
                    moz-do-not-send="true" href="http://www.openssl.org"
                    target="_blank">http://www.openssl.org</a><br>
                  _______________________________________________<br>
                  openssl-dev mailing list<br>
                  To unsubscribe: <a moz-do-not-send="true"
                    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 moz-do-not-send="true"
                    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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
openssl-dev mailing list
To unsubscribe: <a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>