On Wed, Dec 04, 2024 at 09:13:01AM +0000, Winni Neessen via mailop wrote:
> other systems like Mox had a similar issue:
> https://list.mailop.org/private/mailop/2024-November/029764.html Fix
> for this was also to disable session tickets. Since more than one MTA
> is affected, feels like MS might be doing something wrong here.
I think that's reasonable. Below is my latest note on the topic to
postfix-users:
On Wed, Dec 04, 2024 at 07:36:37PM +1100, Viktor Dukhovni via Postfix-users
wrote:
> On Wed, Dec 04, 2024 at 09:04:43PM +1300, Tim Harman wrote:
>
> > > 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.
>
> Perhaps I'm beginning to see the light... In TLS 1.3 session tickets
> work differently than in TLS 1.2, and MSFT may have rolled out TLS 1.3
> support in their email stack somewhat recently.
>
> In TLS 1.2 any session ticket is sent to the client as part of the TLS
> handshake prior to the "finished message", and so before either side has
> turned on the ultimately negotiated traffic encryption. In particular
> though tickets are internally encrypted by a key known only the server,
> the ticket is sent "in the clear". It is possible for an observer to
> see the client using the same ticket later, and "link" the resumption
> to the initial session.
>
> In TLS 1.3, there was much focus on privacy (and latency, but that's a
> separate topic), and linkable tickets were frowned upon. So TLS 1.3
> tickets are sent *after* the handshake is complete, and the timing
> of ticket transmission is somewhat nuanced (but I digress).
>
> What this means is that the TLS 1.3 handshake may be complete, and the
> client sends the EHLO, but the server's response will be not not only
> the application data (250-servername ...<CRLF>...), but also the session
> tickets marked as additional handshake messages rather than application
> data.
>
> So this is where the SMTP server on the MSFT side may be having issues,
> its TLS (1.3) and SMTP stacks may not be interacting properly once
> non-application data arrives post-handshake. One might have hoped
> for better testing...
>
> As for why Debian 12 is doing better, that may have to do with
> that "timing" question, and whether the server sends the tickets
> immediately the handshake completes, or only when it has some
> data to send... This may have changed between OpenSSL versions...
--
Viktor.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
