XMPP: The 'Admin-in-the-middle' or just 'biased scaremongering'?

Recently, we republished our article XMPP: Admin-in-the-middle, showing the unsurprising perspective of an XMPP server administrator. We briefly reply to common reactions.

Always stay in the loop!
Subscribe to our RSS/Atom feed.

The article XMPP: Admin-in-the-middle shows the perspective of an XMPP server administrator. While some people continuously praise XMPP as the “privacy-friendly alternative” to other messengers, we think users should be aware of its downsides: A server-side party (e.g., administrators, attackers, law enforcement) can transparently modify, log, and monitor nearly everything when users communicate via XMPP. We neither say XMPP is the worst communication protocol nor its downsides don’t apply to some other protocols.


We briefly reply to common reactions in the following:

  • Their findings apply to all instant messengers, Admins can always see everything: No, this isn’t the case as other instant messengers (e.g., P2P messengers, Signal) manage accounts and groups on the clients, and/or encrypt most of the data so that server-side parties can’t access it. Of course, other messengers might come with different pros and cons.
  • This won’t work if TLS is enabled: TLS doesn’t change any finding since TLS protects data in transit. TLS was enforced during our latest tests. As soon as the server processes incoming data, the TLS layer is removed, and the server-side party sees the data in cleartext. This is how TLS works.
  • This won’t work if verified end-to-end encryption is enforced: End-to-end encryption (e.g., OTR, OMEMO) doesn’t change most findings since nearly all data processed by the XMPP server remains in cleartext. E2EE protects the content of the message (“what the users write to each other”); however, server-side parties can still access all the metadata of the message. Another upside of verified end-to-end encryption is more protection against spoofed messages (e.g., injected by the admin); however, XMPP clients process and display spoofed messages differently. In some cases, users can’t distinguish between legitimate and spoofed messages in their client.
  • Passwords can’t be accessed; they are hashed by the server: As explained in the article, clients send the password to the server in cleartext when registering a new account or changing the password. The server receives the cleartext password, hashes it, and then stores the hash value in its database. However, ejabberd allows you to log the cleartext password before it is hashed. Enabling/disabling hashing doesn’t affect this.
  • People can use XMPP via Tor to hide their identity: Tor only affects the IP address. The remaining data and metadata is unchanged.
  • This won’t be possible with a hardened XMPP server: Assuming “hardened” means configuring the “most secure” settings of ejabberd, nothing is changed.
  • Test 1 [monitoring XMPP traffic] works for all protocols on the internet: Yes, this may work for many protocols (we never claim otherwise). We wanted to show how external parties can detect XMPP traffic as some people claim XMPP traffic is somehow undetectable and thus can’t be blocked by law enforcement. Contrary to this claim, external parties can detect and thus block XMPP traffic. XMPP is just another protocol, not magic.

For us, it remains unclear whether these reactions try to downplay the issues or should distract from them. The issues are present in XMPP, even if a subset of other communication protocols come with the same issues. Users should be aware of this; especially when reading the claim of XMPP being the “privacy-friendly alternative.” (Plus, these aren’t the only issues with XMPP.)

Read also