Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations

I've had a few comments in response to my previous article, Mitigating the Hetzner/Linode XMPP.ru MitM interception incident which have provided XMPP-specific suggestions for how this could have been mitigated.

While the specific service which was compromised here was an XMPP service, nothing in my prior article was really XMPP-specific, and the article was my considered response to an attack on the TLS ecosystem, without consideration of XMPP in particular.

Channel Bound Authentication. There is an additional mitigation available for XMPP (and potentially for other protocols which use SASL as an authentication layer), namely SCRAM+ (e.g. the SASL method SCRAM-SHA-256-PLUS). This is a channel-bound authentication mechanism in which

a client has to prove to a server knowledge of a password;
the server has to prove to the client it also knew the password;
this authentication is performed in a channel-bound (and therefore MitM-proof) manner.

Note that the non-plus variety (SCRAM, e.g. SCRAM-SHA-256) omits the channel binding part, and is therefore not an adequate mitigation against MitM.

Because a server has to prove knowledge of a user's password in a channel-bound fashion, even the attacker in the XMPP.ru incident would not have been able to successfully impersonate the server to a client using this authentication mechanism, even after successfully acquiring a TLS certificate.

SCRAM+ is not specific to XMPP, as it is a SASL mechanism. SASL is the IETF's generic pluggable authentication mechanism infrastructure, so any application protocol which uses SASL for authentication (e.g. POP3, IMAP, SMTP, IRC, AMQP, LDAP, and countless other protocols) can potentially benefit from it.

XMPP: requirements for effective mitigation. In order for this mitigation to work, the following must be observed:

Your XMPP server must support SCRAM+ (not just SCRAM).
Your XMPP client must support SCRAM+ (which people now seem to be referring to as “channel binding”) (not just SCRAM), and must be competently designed to mitigate this attack;
Your XMPP client must enforce use of the SCRAM-SHA-256-PLUS SASL method (or the equivalent SCRAM-...-PLUS method parameterised using another hash function) and must refuse to use another authentication mechanism if a server suddenly stops supporting it (and, for example, suddenly starts asking for passwords in plaintext using the PLAIN SASL method).
You must configure your XMPP client correctly to use these features.
Since SCRAM+ authenticates a server by having the server prove its prior knowledge of your password, it is only as secure as your password. You should randomly generate a unique (non-memorable) password with 128 bits of entropy and keep it in a password safe. Don't reuse the password.

I would not trust any XMPP client to do these things correctly unless the author of that XMPP client has expressly documented it as doing so, or you have personally tested the XMPP client and found that this is the case.

Adoption of XEP-0474 is likely to aid in the correct configuration of this by providing some automatic protection against MitM-based downgrade attacks, so if you want to use SCRAM+ with XMPP, try to choose both a client and a service provider which support XEP-0474 if possible.

XMPP: incomplete mitigation. Please note that there is a massive gap here in that you don't necessarily know how XMPP server-to-server federated communications are authenticated by a) your own XMPP provider initiating outgoing connections, and b) other XMPP servers connecting to your own XMPP provider. These connections cannot benefit from SCRAM+ channel binding and thus remain vulnerable. For this reason I do not believe that the SCRAM+ channel binding solution, on its own, is as valuable as its proponents are perhaps claiming.

This is not a relevant concern if you only communicate with users using the same XMPP provider.

XMPP S2S: DANE. It is possible for the server-to-server links of the XMPP ecosystem to be better secured, for example using DANE. The Prosody XMPP daemon supports enabling this, for example. I would strongly encourage XMPP services to setup DNSSEC and DANE if possible and to enable DANE verification for S2S connections. (If you do this, please remember to document this policy on your website! People need to know.)

Priorities: E2E first. While it's certainly better to use SCRAM+ than to not use it, I would like to warn people against spending their finite time deploying these mechanisms that, if they have not already, they could instead spend deploying an end-to-end encryption mechanism. Even if you use channel binding:

you can't know how (or whether) server-to-server XMPP connections are secured;
a (local or remote) XMPP server operator might be compromised despite the very best efforts of that operator;
a (local or remote) XMPP server operator might turn out to be malicious and eavesdrop on your communications.

Some of these risks are inherent to the design of a federated protocol without end-to-end encryption and will simply always exist. If you are using XMPP without using an end-to-end encryption mechanism such as OMEMO, I don't think you should spend a single second deploying any measure proposed in this article before you first deploy OMEMO or similar. E2E is a basic expectation of any instant messaging protocol in this day and age and the added security that channel binding or any other security mechanism can offer your communications pales by comparison.

Metadata. You should be advised that even with E2E deployed, a system like XMPP intrinsically does not protect communications metadata, such as who is communicating with whom, how much, and when. Compromise of an XMPP server (or the XMPP server proving malicious) leaks this information. This information can be much more sensitive — and much more revealing — than people realise. This is an intrinsic limitation of a client-server federated protocol like XMPP. You need to make a determination if this risk is acceptable to you; consider the ex-NSA directory Michael Hayden's statement that “we kill people based on metadata”.

If you require protection against metadata, you are going to receive exponentially more protection if you adopt something like Ricochet, which routes all communications between parties directly over Tor hidden services, using onion addresses as handles (a fact which also renders it immune to MitM and the attack performed on XMPP.ru). I hesitate to recommend it because I loathe the sole available client, which is little more than a minimal tech demo, but the security of it is inarguable.

Reflections on authentication mechanisms. I've previously written about the various kinds of authentication mechanisms found in application protocols. It's certainly the case that the popularity of TLS nowadays has led to the “plain text over secure channel” authentication approach becoming overwhelmingly popular (especially in the age of the web, where limitations of the web largely preclude doing anything else, WebAuthn and client certificates aside).

There is a whole ecosystem of interesting non-plaintext-based authentication mechanisms which seem to be relatively unused by comparison: client certificates, TLS-PSK, SRP and similar zero-knowledge protocols, SCRAM, channel-bound SCRAM+, Kerberos, etc.

A revival of interest in these protocols is certainly welcome. The particular curiousity about SCRAM+ is it essentially uses a secret known by the user (their password) to perform an additional step of server verification in addition to that provided by the CA infrastructure. This is an interesting “trick” and its properties in some ways give it a (very slight) resemblance to TLS-PSK, which also enjoys mutual authentication via mutual knowledge of a shared secret.

Context of Certificate Transparency. Some people were slightly confused by my coverage of gaps in the Certificate Transparency infrastructure in my prior article given that this wasn't a relevant issue in the specific attack that was perpetrated in the XMPP.ru incident; as such any enhancements to the Certificate Transparency infrastructure wouldn't have prevented this attack.

My reason for this emphasis is that it was only in the aftermath of this incident that it came to my attention that CAs are still technically allowed to issue unlogged certificates, and it appears that there are some CAs which will do so just on the basis of a customer requesting it. Frankly, I'm not happy about this. If the attacker in this incident had been more competent they could have taken advantage of this, and on the principle that attacks only get better, there's a real risk of this being exploited in future — hence why I am drawing attention to it, both with my previous article and with a new article I'm publishing today, Expect-CT Lite: A humble proposal for minimal CT enforcement in TLS certificates. The fact that this was not the subject of the recent attack does not mean this issue should not be addressed.