August 26, 2013

The State of TLS on XMPP (1)

Inspired by some recent discussion on the prosody-users mailing list, I started working on a tool to investigate the strength of the encryption an XMPP server offers. https://www.ssllabs.com/ has such a test, which gives a server a grade between A and F and shows a lot of helpful information about the SSL configuration, what features might be considered weak or undesirable, issues with the chain, etc. However, this only grades HTTPS servers, with no support for XMPP.

XMPPoke

The tool I’ve developed is a Lua script that will calculate a server’s score according to the same algorithm as used by ssllabs. I hope to release this in the next couple of days. One notable difference is that ssllabs.com will cap a grade to B if the server is vulnerable to the BEAST attack. As I don’t understand enough about that attack to say whether XMPP is vulnerable, I have not included it.

Of course, anything that reduces a complex problem like “security” to a single letter will have some caveats. First of all, an A does not mean the encryption is perfect and will stay that way forever. For example, by scoring high enough in other areas it is possible to obtain an A while still having weak ciphers like DES-CBC-SHA enabled. Maximizing the score is also not the goal: obtaining the maximum will lose compatibility with many (older) clients.

On the other hand, obtaining less than an A is definitely cause for concern. This means that the security has serious problems in one or more ways. For all but the most outdated servers, it should be possible to configure it properly and obtain an A.

The tool will also try to simulate the handshake of a number of XMPP clients, to determine which ciphersuite the server will select for that client. This is still under development, currently shown results might not be accurate.

Testing the xmpp.net list

xmpp.net maintains a list of publicly accessible XMPP servers. Some clients can download this list and register a user in-band. As this might be the first stop for lot of new users, we should hope that they have their encryption sorted. Therefore I decided to grade the encryption strength offered for client-to-server connections by these servers. The results can be seen here.

Statistics

8 did not respond.
57 got an F.
17 got a B.
26 got an A.

Of the 100 servers that did respond, 43 got an F due to an untrusted or invalid certificate. Ignoring that, their grades would be:

23 still had an F (due to SSLv2 support).
15 got a B.
5 got an A.

Certificates were untrusted because (multiple can apply):

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

Protocol versions (servers can support multiple):

37 supported SSLv2 (which is known to be insecure and should not be used anymore).
100 supported SSLv3.
98 supported TLSv1.
38 supported TLSv1.1.
38 supported TLSv1.2.

Key sizes:

14 used a 1024 bit RSA key.
56 used a 2048 bit RSA key.
30 used a 4096 bit RSA key.

Cipher suites:

80 supported weak cipher suites (56 bits or less).
49 supported EXPORT cipher suites (40 bits).
29 supported at least one ephemeral cipher suite (enabling forward secrecy).

Conclusion

An alarming number of public XMPP servers allow for very weak encryption to be used. While most clients are unlikely to actually use those ciphers, older or badly configured clients are at risk.

Many servers also have one or more trust issues, causing their certificates to be considered untrusted. This can confuse users, or teach them bad security habits like accepting untrusted certificates manually every time they connect.

I urge the operators of xmpp.net to remove servers that have expired, self signed or invalid certificates. Optionally also those with certificates from alternative CAs (like CACert) and servers with major security issues (like still supporting SSLv2). Even the flagship Jabber server, jabber.org, has a number of weak ciphers enabled.

Future work

Though a website with automatic checking, like https://www.ssllabs.com/, would be great for XMPP, I don’t want to invest the work necessary to set that up. Instead, I intend to publish a report like this regularly, something like once every 1 to 3 months (depending on whether anyone actually improved something) and release the tool, so other people can check the security of their own server.

In the next couple of days, I hope to be able to also do the same process for server-to-server connections.

xnyhps’ blog