On Mon, Jul 04, 2022 at 04:32:42PM +0200, Spil Oss wrote:
> Since migrating to OpenSSL 3.0 we are experiencing intermittent issues
> in TLS handshakes.
> [...]
> the client returns a a Fatal alert, unexpected_message.
>
> See also
> * https://github.com/openssl/openssl/issues/18690
This is due to a regression in OpenSSL 3.0, where the internal session
cache (limited to one element in extant Postfix releases) got a fancy
new expiration time order (vs. simple LRU in 1.1.1), but this can now
mean that on cache overflow the element being added from an external
cache might get immediately removed and invalidated.
Since Postfix's one element internal cache often overflows, we are, when
built with OpenSSL 3.0, prone to seeing this problem with clients that
don't use session tickets.
Some day the OpenSSL issue will be resolved upstream, but there are many
systems that may not see the OpenSSL fix for some time, and may get an
updated Postfix release first. So the simplest work-around is to simply
disable the internal cache. It is not that useful.
--- src/tls/tls_server.c
+++ src/tls/tls_server.c
@@ -751,6 +751,7 @@ TLS_APPL_STATE *tls_server_init(const TLS_SERVER_INIT_PROPS
*props)
sizeof(server_session_id_context));
SSL_CTX_set_session_cache_mode(server_ctx,
SSL_SESS_CACHE_SERVER |
+ SSL_SESS_CACHE_NO_INTERNAL |
SSL_SESS_CACHE_NO_AUTO_CLEAR);
if (cachable) {
app_ctx->cache_type = mystrdup(props->cache_type);
If the client supports resumption, but does not support session tickets,
and there's no external cache (recommended default), and the client is
hammering away at your server with a concurrency of one, and somehow
hitting mostly the same smtpd(8) process, then the single-element
cache might be of some help, but this is so unlikely as to be ignorable.
--
Viktor.
