Hi Ian, Thanks for the report!
Your colleague John Foley suggested to treat this error as unrecoverable: https://mta.openssl.org/pipermail/openssl-dev/2015-March/001030.html The error is set while processing the ServerHello, at which point the PAC has already been sent to the server in the ticket in the ClientHello, and it's the server's call whether it'll be resuming. So either (a) we make the assumption that the server would agree that the PAC has expired and not attempt a resumption - and we make the resumption attempt an internal error; or (b) the client-side check for expiration would have to be moved to an earlier place in the handshake. I am afraid that you know better than me what the intended behaviour is. How about you describe the complete correct flow and propose a patch? Cheers, Emilia On Mon, Aug 10, 2015 at 5:34 PM, Ian McFadries (imcfadri) < imcfa...@cisco.com> wrote: > > > I am trying to determine if the tls_session_secret_cb return value is used > to indicate an unrecoverable error has been encountered > > (i.e. bad pointer for data needed to calculate secret) or if it is > intended to be an indicator that the session secret is deemed > > invalid (EAP-FAST PAC expired resulting in new session therefore determine > that secret should not be calculated). > > > > The code I am working on is using the tls_session_secret_cb return value > as the latter specified above, and that resulted in our > > implementation of EAP-FAST to break when a PAC expires after we picked up > release 1.0.1l of OpenSSL. A change was made in s3_clnt.c > > ssl3_get_server_hello method at line 889. Previously, if > tls_session_secret_cb returned 0 no action was taken, but the change > > resulted in SSLErr if tls_session_secret_cb returned 0. > > > > I believe that we should treat the tls_session_secret_cb return value to > indicate an unrecoverable error only. Then in the scenario > > where the PAC expires, although we would not calculate the secret, it will > work fine since the secret will be calculated later in > > OpenSSL when servicing the client key exchange. > > _______________________________________________ > 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
