August 28, 2013

The State of TLS on XMPP (2)

---

To follow up on my previous post, the results for s2s encryption can be seen here, now also with XEP-0092 reported version and OS for every server.

I’ve also published the code on https://bitbucket.org/xnyhps/xmppoke. The code is still in a pretty unpolished state, many paths are fixed for my own machine. Note that it requires a patched luasec to be available for certain features. To properly test s2s support, you also need a certificate and key (I don’t know how trusted the certificate needs to be, for my tests CACert was good enough).

I tested the xmpp.net list again. This time, 6 servers did not respond or were unreachable. 2 servers are actually Google Apps servers (which does not support TLS on s2s), bringing the total again on a nice, round 100. 1 server (jabber.at) had starttls as a required stream feature. 2 servers (rkquery.de and jabber.schnied.net) required the initiating server to also present a client certificate.

Statistics

• 46 got an F.
• 25 got a B.
• 29 got an A.

All of the 46 F’s had some trust issues. Ignoring those, their grades would be:

• 4 got an F due to SSLv2 support.
• 39 got a B.
• 3 got an A.

Certificates were untrusted because (multiple can apply):

• 9 had an expired certificate.
• 6 had a self signed certificate.
• 29 had a self signed certificate in the chain (27 of these were CACert).
• 21 used a certificate which was not valid for the intended host.

Protocol support:

• 4 supported SSLv2.
• 100 supported SSLv3.
• 98 supported TLSv1.
• 38 supported TLSv1.1.
• 38 supported TLSv1.2.

4 servers with SSLv2 support is a surprising decrease from the 37 that support SSLv2 on c2s connections.

Key sizes:

• 15 used a 1024 bit RSA key.
• 55 used a 2048 bit RSA key.
• 30 used a 4096 bit RSA key.

Cipher suites:

• 79 supported weak cipher suites (56 bits or less).
• 16 supported EXPORT cipher suites (40 bits).
• 31 supported at least one ephemeral cipher suite (enabling forward secrecy).

Conclusion

I expected these results to be more or less the same as for c2s connections. However, a surprising number of servers have SSLv2 disabled for s2s connections, but not for c2s connections. The number of servers with support for 40 bit EXPORT suites also decreased by 33.

In this list, lack of TLS support on s2s is limited to GTalk – and other domains hosted by Google. However, there was only one server that actually required encryption. This is unlikely to improve much while Google is refusing to do TLS on s2s connections.

Edit: Two servers on the list (jabber.rootbash.com and jabber.iitsp.com) have TLSv1 disabled, so support only SSLv3. In my testing, OpenSSL will actually start a TLSv1 handshake when configuring it to enable SSLv3 and up (“sslv23” with “no_sslv2” in luasec). This means that any OpenSSL based server will only be able to federate to those two servers when they either allow SSLv2 or do a SSLv3-only handshake. Both are very undesirable options.

Future work

One thing I did not test was which servers allow SASL EXTERNAL for other servers which presented a trusted client cert (because I did not have such a certificate available to test with). This would be interesting to test, because it means the less secure dialback can be avoided.

---