Re: STARTTLS vulnerabilities

[Matthew Wild <mwild1 () gmail com>]

On Wed, 11 Aug 2021 at 08:52, Hanno Böck <hanno () hboeck de> wrote:

> On Wed, 11 Aug 2021 08:09:57 +0100
> Matthew Wild <mwild1 () gmail com> wrote:
>
> > XMPP has some additional protections against this in its design. It is
> > required, after TLS negotiation, for both parties to discard the
> > pre-TLS XML stream and negotiate a new one after TLS has been
> > established[1].
>
> This is actually not much different from how STARTTLS works in SMTP or
> IMAP. You are basically advised to throw away all state from pre-TLS.
> But yet here we are with > 40 vulnerabilities.

The difference with XMPP is that it is a highly structured protocol, so
it's less vulnerable to simple injection compared to line-based protocols.
It is not just advised to throw away pre-TLS state, but a required step of
the TLS upgrade is starting a new XML stream from scratch after TLS
negotiates successfully. When implemented with commonly-used XML parsers,
this means instantiating a new parser instance, and that step will
naturally discard any data that was fed to the pre-TLS parser instance.

I'm not claiming that bugs are impossible, or that they don't exist - only
a dedicated review of implementations would be able to confirm this. But I
stand by my original statement that XMPP has more protection against such
attacks than SMTP, IMAP and many other protocols using STARTTLS.

Regardless, XMPP is gradually moving away from STARTTLS for other reasons.
Recent advances such as ESNI, round-trip reduction, the ability to use
generic TLS middleware (load balancers, etc.) and generally reach through
restrictive network environments are all drivers of this change. I think
this is ultimately a good thing.

Regards,
Matthew