Viktor Dukhovni:
> On Mon, Oct 17, 2022 at 04:09:25PM +0200, GCore GmbH - Gerald Galster wrote:
>
> > > If possible, please ask the other user whether the alternative
> > > certificate again sports a mismatched hostname. It is somewhat
> > > plausible that the Microsoft bug doesn't fire when certificate
> > > chain validation bails out early due to the mismatched hostname.
> >
> > Attached is the pcap of another server where Outlook is able to
> > send emails with session tickets enabled.
> >
> > This server (<redacted1>) and the other (<redacted2>)
> > are running the same software stack:
> >
> > - CentOS 7
> > - postfix-3.4.16 (self compiled)
> > - openssl-1.0.2k-25.el7_9.x86_64
> > - certbot-1.11.0-1.el7.noarch
> >
> > (no hostname mismatch anywhere)
> >
> > Letsencrypt chain cerfiticates are identical on both servers. Only
> > difference is that <redacted1> cert has three SANs (active/active with
> > dovecot replication). But this does not matter from a ssl perspective.
>
> Yes, indeed session ticket ACKed by server. Assuming the Windows client
> was indeed patched, the only visible difference is minor cert defailts
> (3 SANs).
>
> > I think it's Microsoft's turn to check what's going on.
>
> This bug feels like uninitialised data, which is influenced by whatever
> random thing lands in memory as a result of previous computations.
Or some out-of-bounds memory write.
Any light on whether the problem may also affect connections from
Microsoft MTAs? As metioned these failures may be less noticeable,
and reports would arrive only after mail piles up in remote queues.
Wietse
