On Fri, Oct 01, 2021 at 02:15:05PM +0100, Jeremy Harris via Exim-users wrote:
> On 28/09/2021 23:41, Viktor Dukhovni via Exim-users wrote:
> >> - fast-ramp queue run
> >> - native SRS
> >> - TLS resumption
> > I'd like to ask, if I may, how TLS resumption interacts with DANE or
> > other authenticated TLS policy, assuming potential earlier
> > unauthenticated TLS connections to the same IP:port or name:port on
> > behalf of some other domain (or via an alternate "router") which did not
> > require an authenticated connection, or otherwise had a different set of
> > TLS requirements.
> If enabled for a target host (default being no)
> then the session cache lookup key is the unadorned IP.
I guess you won't be surprised if I suggest you should consider a more
security-aware design, that takes the extant security policy parameters
into account when constructing the lookup key.
Otherwise, when a e.g. a connection to a DANE-enabled destination
follows a connection to an unauthenticated opportunistic TLS connection
with the same underlying host IP, the DANE connection is subject to MiTM
if the original connection was successfully compromised.
Security aside, we also found it useful to salt the lookup key with the
remote "EHLO" response name, in order to work better with Microsoft's
SMTP servers which have split caches:
S: 220 ...
C: EHLO amnesiac
S: 250-<servername> [<SP> junk]
S: 250 STARTTLS
We include the <servername> in the cache lookup key, so that we can find
the "right" session for split caches behind a load balancer. The Google
SMTP servers have a shared session ticket key and respond with a common
If you're curious how Postfix computes the lookup key, I can point you
at the code. Basically it computes a SHA256 digest of all relevant
destination and security parameters and uses that in the key...
> >> - faster TLS startup
> > May I ask what this means?
> Caching of the CA bundle, and similar setup, by loading it in the
> daemon process (which forks for receive processes).
Makes sense, thanks.