Hi there, I'm working on an application that shares SSL_SESSION pointers between SSL_CTXs in multiple threads. The logic for sharing the session is roughly as follows:
lock(&mtx); sp = get_cached_session_pointer(); if (!SSL_set_session(ctx, sp)) { SSL_set_session(ctx, NULL); } unlock(&mtx); r = SSL_connect(ctx) if (r > 0 && !SSL_session_reused(ctx)) { lock(&mtx); set_cached_session_pointer(SSL_get1_session(ctx)); unlock(&mtx); SSL_SESSION_free(sp); } With OpenSSL 1.0.1e, I'm running into what looks like a race condition in which SSL_connect will call ssl3_get_new_session_ticket when it is reusing a shared session. In this case, there is a race when multiple threads simultaneously enter this state and both observe ctx->session->tlsext_tick to be non-NULL, both will call OPENSSL_free, and this can crash, especially with custom allocators. This race triggers quite rarely doing about 7 connections per second (that's about all the information I can offer as to the environment), but "quite rarely" is unfortunately still often enough to need to fix this. It seems to me that the only way to do this safely is for any time we enter the state SSL3_ST_CR_SESSION_TICKET_[AB], we call ssl_get_new_session prior to the ssl3_get_new_session_ticket call. If we were to just serialize the ssl3_get_new_session_ticket alloc / free, it seems that the race still exists -- two new tickets may be negotiated, but only one will wind up stored in the session. I imagine this would have consequences in later communications. Alternatively, hanging the tlsext_tick, tlsext_ticklen, and tlsext_tick_lifetime_hint off of the SSL_CTX instead of SSL_SESSION would also work. Serializing SSL_connect also fixes it (of course) but adding indeterminate latency to future connects to solve the problem doesn't work for me. I'd greatly appreciate feedback as to whether this analysis makes sense (and if so which approach to fixing it might be preferable for submitting a patch) given that I'm more of a concurrency and performance guy than a crypto guy. I'm also always open to being told that I'm doing it wrong; in this case, I would appreciate insight into how I might better implement the session reuse code to avoid this race. --dho ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org