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. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev