Wait what, since smtps STARTTLS is quite old I though it's by now
well known that _any_ form of late TLS is a massive security vulnerability...
Some form of transport layer security not being the default and starting late would for me on itself enough of a reason to exclude XMPP from a lot of things.
I'm not aware of any vulnerability in XMPP due to the use of starttls. If you (or anyone) can prove otherwise, I'd be happy to see that. We can do coordinated disclosure across projects via the XSF.
There is no attack surface because the data exchanged before the upgrade is mostly superfluous. I always felt like the refusal in the WG to add a dedicated TLS-only port in the spec was more feeding someone's conception of niceness than anything else.
Happy to see it has become de-facto supported by now though. I tried writing a client in the late 2000s with .NET TlsStream and it was not a great experience.
If any data which can potentially be exchanged before STARTTLS can affect the connection establishment in any way (except simply failing it) then there is a problem because of MITM attacks.
If there is nothing like that then there is no point to have STARTTLS.
Idk. if that is the case for XMPP. Note that what matter is what can be send, not what is send as a MITM attacker can modify anything.
But even if not, if there is a risk of an implementation being affected by anything send by a MITM attacker impersonating a server it's an problem.
Like attacking vulnerabilities in XML parsers.
Either way, I have not time to look at the protocol, but STARTTLS is security wise generally a bad idea.
> If there is nothing like that then there is no point to have STARTTLS.
I agree that there is really no benefit to have STARTTLS with modern TLS implementations (e.g. now that we have SNI everywhere), but this was not entirely the case last time the XMPP core specs were revised. However there are multiple benefits to be gained from switching, and that is a change already in progress for some time. I don't doubt that the next revision of the XMPP RFCs will reflect this.
Wait what, since smtps STARTTLS is quite old I though it's by now well known that _any_ form of late TLS is a massive security vulnerability...
Some form of transport layer security not being the default and starting late would for me on itself enough of a reason to exclude XMPP from a lot of things.