On Sun, Jul 19, 2009, Jan F. Schnellbaecher wrote: > Hi, > > I am using 098h with the non default configure option 'enable-tlsext' and > have a > problem with the TLS extension servername in conjunction with ssl session > caching. > > It seems that sessions that contain the SNI extension will not be cached by > openssl. (I tried with FF 351) > > During the handshake openssl calls the function ssl_get_prev_session > (ssl/ssl_sess.c) which calls tls1_process_ticket (ssl/t1_libc). Latter sets > the > member tlsext_ticket_expected of the openssl object to 1. > > For the first handshake no session will be found and a new one will be created > in ssl_get_new_session (ssl/ssl_sess.c). Here the session id will not(!) be > set > in case that tlsext_ticket_expected is 1. > > At the end of the handshake the session will not be saved in ssl_update_cache > (ssl/ssl_lib.c) because the session->session_id_length is 0! > > Tweaking the ssl context by setting SSL_OP_NO_TICKET enables openssl to write > the session in the session cache, but when searching for an existing session > tls1_process_ticket returns 0, which means cache miss. The comment in the > source is > > /* If tickets disabled indicate cache miss which will > * trigger a full handshake > */ > > Any idea how I can make openssl to cache the initial handshake and let it find > the session for further requests or an explanation why theses extensions are > handled this way? >
Is that a bug or is OpenSSL using stateless session resumption? FF also supports that. In that case the session cache is not used. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
