> On Nov 28, 2018, at 6:31 PM, Claus Assmann <ca+ssl-users@xxxxxxxxx> 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. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
