[openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method

[Viktor Dukhovni]

On Fri, Jul 24, 2015 at 01:46:36AM +0300, Jouni Malinen wrote:

> I'd assume this is with the more standard TLS SessionTicket which is not
> what EAP-FAST is..

Correct.

> > The order of events is:
> > 
> > 	/* Once only */
> > 	ctx = SSL_CTX_new(SSLv23_client_method());
> > 
> > 	/* Per connection */
> > 	ssl = SSL_new(ctx);
> > 
> > 	/* Protocol support varies per server, so not set via global context */
> > 	SSL_set_options(...);
> 
> This is all same..

Sure.

> > 	/* restore appropriate session from the client cache */
> > 	session = ... ;
> > 	if (session)
> > 	    SSL_set_session(ssl, session);
> > 
> > 	SSL_connect(ssl);
> 
> While this is not.
> 
> > What are you doing to associate a previous session with a new SSL
> > connection?
> 
> With EAP-FAST, I don't really have a cached session in this sense for
> deriving the keys and information for ClientHello. Instead of
> SSL_set_session(), I'm only calling SSL_set_session_ticket_ext() before
> SSL_connect() to provide the externally (to OpenSSL) stored
> SessionTicket data. With TLSv1_method(), this data goes out in
> ClientHello; with SSLv23_method() it does not (only an empty request for
> standard session ticket included, not the SessionTicket from EAP-FAST
> PAC data).

Thanks makes the issue more clear to me, perhaps others were there
already, but I think this context is helpful.

> If I were to store the TLS session during which the EAP-FAST PAC was
> provisioned and then issue SSL_set_session() with it here, I would
> indeed get abbreviated handshake with that session (non-empty Session ID
> in ClientHello), but that's not how EAP-FAST works. The Session ID is
> supposed to be empty here and instead of the standard session ticket
> mechanism, the keys get from SSL_set_session_secret_cb() registered
> callback function which derives the secret in EAP-FAST specific way
> (master_secret = T-PRF(PAC-Key, "PAC to master secret label hash",
> server_random + client_random, 48)).

Any chance you have a standalone test program that works with
TLSv1_client_method(), but not with SSLv23_client_method() (and
SSLv2 disabled).  Such code if added to "make test" might ensure
the problem does not come back after is is fixed.

What would be excellent is a program that is both the client and
the server (talking to itself over a socketpair perhaps, though
that might not be portable to Windows, but perhaps it suffices
for the test to run on Unix-like systems...).

-- 
	Viktor.