[openssl-dev] tls_session_secret_cb method return value

[Emilia Käsper]

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) <
imcfadri at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150811/2ece2622/attachment-0001.html>