[openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free

[Viktor Dukhovni]

> On Nov 28, 2018, at 6:31 PM, Claus Assmann <ca+ssl-users at esmtp.org> wrote:
> 
> Thanks for the reply, it helped me adding some more debugging
> statements to various places to track down the problem:
> it is due to a change in TLS session handling in TLSv1.3.

Thanks for following up, much appreciated.

> It seems there are multiple SSL_SESSION structures for a single SSL
> connection (SMTP session).  The callback installed using
> SSL_CTX_sess_set_new_cb() was called twice for the same SSL connection
> and the code was written to handle only one callback per connection.

Yes, by default the OpenSSL library now issues two session tickets
for each full (non-resumed handshake), and a new session ticket
after each resumption.

Recent versions of the Postfix SMTP server, when linked against OpenSSL
1.1.1 ask the library to issue just one session ticket after a full
handshake:

  https://github.com/vdukhovni/postfix/blame/postfix-3.3/postfix/src/tls/tls_server.c#L507-L521

and none on resumption if the current ticket is still valid (existing
code from Postfix 2.11, which implements session ticket key sharing
and rotation for a pool of Postfix SMTP servers on a single host):

  https://github.com/vdukhovni/postfix/blame/postfix-3.3/postfix/src/tls/tls_server.c#L507-L521

Linkability of sessions is not in my view a concern for SMTP, and SMTP
clients either don't cache session tickets at all, or cache at most one,
so issuing two initially and avoiding re-use is largely wasteful.

> This resulted in a "use after free" situation. Sorry for the false
> alarm.

Makes sense.  I did look briefly for potential issues in the library,
that matched your stack trace (freeing the peer's DH public key), but
did not find any smoking gun.  I might however add belt-and-suspenders
safety in one code path were I think that the current safe behaviour
could prove fragile as the code evolves.  So it has not been entirely
unproductive.

-- 
	Viktor.