Hello, 2024年12月4日(水) 18:41 Viktor Dukhovni via mailop <mailop@mailop.org>:
> 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... I'm the one who wrote https://github.com/golang/go/issues/70232#issuecomment-2463566317 to share a similar issue in Go's TLS stack. It's very interesting that Postfix + OpenSSL also is experiencing a similar issue. Would you mind sharing the version details so that I can relay it to the Go team about how OpenSSL handles it in a later version? -- Tanabe Ken-ichi HENNGE K.K. / Cloud Product Development Division kenichi.tan...@hennge.com +81-3-6415-3660
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
