> This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. This is a common

> This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. This is a common misconception about STARTTLS. It is certainly possible to implement it poorly (and that has certainly happened). But there are no inherent security issues with a correct implementation. An active attacker can just as easily block TLS handshake packets on a direct TLS connection. The problem used to be that many software implementations (not just XMPP) would happily continue unencrypted if STARTTLS was not offered. But these days everyone requires TLS, and will not proceed to connect unless TLS is in use (regardless of whether it is negotiated or "direct"). However the future is certainly direct TLS, that has been obvious for some time. It has many advantages, such as allowing the use of off-the-shelf middleware such as loadbalancers and proxies, and bypassing certain firewalls. It's also easier to implement, and there is of course the (relatively new) ESNI which is beneficial.