4 ms·

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 d

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.

sascha_sl 5y ago
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.
dathinab 5y ago
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. Even if it does(?) work ok for XMPP.
- MattJ100 5y ago
  > 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.
  - dathinab 5y ago
    thanks for clarifying

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.

sascha_sl 5y ago

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.

dathinab 5y ago

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. Even if it does(?) work ok for XMPP.

MattJ100 5y ago
> 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.
- dathinab 5y ago
  thanks for clarifying