The State of TLS on XMPP (2)
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.
- 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.
- 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.
- 15 used a 1024 bit RSA key.
- 55 used a 2048 bit RSA key.
- 30 used a 4096 bit RSA key.
- 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).
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.
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.
- The Wrong Number Attack
- Common DH groups
- Out with octopress, in with Hakyll
- Validate the encoding before passing strings to libcurl or glibc
- Multi-end to multi-end encryption
Do you appreciate what you read? You can donate using Bitcoin:
Copyright © 2016 - Thijs Alkemade
Site proudly generated by Hakyll.