On Tue, Aug 09, 2022 at 04:22:44PM +0100, Tom McLoughlin wrote:
> > The resumption problem can be worked around by setting the server-side
> > session cache database empty (the default setting):
> >
> > smtpd_tls_session_cache_database =
> >
> > This is the recommended setting, since clients should be using session
> > tickets instead.
>
> After reviewing the setting you provided here, I think I figured out
> the issue, this was set to store session cache in a local DB which
> wasn’t storing session tickets across the cluster.
You're confused here. (Server-side stateless) session *tickets* are
stored by clients with no server-side storage. If your servers are
behind a load-balancer, the client's ticket might be presented to a
server that does not know how to decrypt it (absent some mechanism to
ensure synchronisation of session ticket keys across hosts, that Postfix
does not have). But even if that happens, the server will just perform
a full handshake.
Server-side storage is used for "stateful" session caches, where the
client sends just a session-id, and the server locates the session in
its internal session store (memory or external). It is this that
can cause issues in OpenSSL 3.0 (until the fix is released and adopted
by distributions).
> This was causing a client to connect on one server, then switch to the
> other and produce a fatal error (which didn’t really make anything
> unusable).
Switching between servers should not be a problem. A "decode error"
suggests a TLS protocol issue, perhaps the one fixed in 3.0, though
as mentioned, I'd expect a slightly different alert.
> After correcting this and monitoring for the issue it’s finally gone
> away.
But if turning off server-side session cache storage solved the issue,
perhaps it was the resolved 3.0 bug after all.
--
Viktor.
