On 04/12/2024 7:45 pm, Viktor Dukhovni via Postfix-users wrote:
On Wed, Dec 04, 2024 at 12:13:13PM +1300, Tim Harman via Postfix-users
wrote:
FIXED!!!!
smtpd_tls_session_cache_timeout = 0
This is very odd, because:
- Session tickets are either successfuly decrypted or not.
- If yes, the TLS handshake proceeds more quickly, and
the client can detect the fact that the handshake was abbreviated
(session resumed), if it cares to check.
- If not, the server ignores the client's ticket, and performs a
full handshake.
Regardless, the TLS handshake was actually completing, and the client
even sent a second SMTP EHLO. So it is **very** surpising that at
that point the client suddently decides it does not like the TLS
session it got.
That's why I hadn't bothered touching it before, I thought "It can't be
that" but I have conducted multiple tests and each time with it set to
604800 it fails, and set to 0 it doesn't.
This is instantly resolved the issue
Previously I had smtpd_tls_session_cache_timeout = 604800
I noted that turning this to 0 also disabled session tickets, and I'd
read
this: https://github.com/mjl-/mox/issues/237 (After searching MailOp)
This seemed to be about TLS handshake failures, not connection loss
after a successful handshake... Did I misunderstand?
No, you don't misunderstand. Their ticket/bug is about TLS handshake
failing.
I was clearly getting through that as you can see the second EHLO was
issued after STARTTLS had completed.
But the dates lined up with when it started failing for me and them, and
the error message from Microsoft "Security status InvalidToken" seemed
vaguely to sound like a "Session Ticket" even though they use the word
Token.
But - I'm guessing, just guessing.
So there must be something going on in the version of Debian I have
(10)
where TLS session tickets aren't working/negotiated/stored correctly.
No, that's unlikely. I am curious whether you also had a (stateful
resumption) server-side session cache configured, or just the timeout
(tickets only)?
I had this configured as well:
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
The duration you were going with was needlessly high, no client should
be holding on to your tickets that long. Is there more detail anywhere
that you found explaining how/why MSFT email servers (mis)handle
tickets?
No, just that ticket I linked to. The thing is, the dates line up with
when I stopped getting email from Outlook. I didn't notice, but going
back and looking at logs ~24 Oct is approx when they started appearing
and mail started failing.
I am (hopefully obviously) not very good with the details around SSL
etc, so to be clear my "it must be this" statement is very much me
having a guess based on what I saw, not hard facts.
I'm happy to test/make changes now if you want me to try things, now
that I know how to reproduce it and fix it (and I have a safety net with
a backup MX now) - so happy to try things if you think it's worthwhile.
Thanks again!
Kind Regards,
Tim Harman
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
