XMPP (Jabber) is one of the most secure methods of instant messaging.
Of course, you need to use end-to-end (e2e) encryption (OTR or OMEMO, each has its own advantages) and route XMPP messenger traffic through the Tor network. Otherwise, the content of your messages and your real IP address will be available to XMPP server you and your conversation partner chose for registration.

What does XMPP server know about users

What data is processed by server

This info is not exhaustive. You should check XMPP Wiki and XMPP.org for more information.

So the server knows the user’s:

  • password (in XMPP protocol it’s called credentials);
  • registration date and time
  • IP address;
  • presence (online / offline), if offline – timestamp of last available presence;
  • which client is used (to some extent);
  • roster (buddy list) content and time, when buddies were added / deleted from the list;
  • messages (and its recipient, sending time, status of delivery, method of encryption).

With this information anyone can create a chart showing which users are on each other’s buddy list and how often they write to each other. Or take into account the time of activity (online/offline and messaging) of each user.

Information from the XMPP server can be mapped to a database of other services. For example, presence (online/offline) and time of activity (messaging) can be correlated with activity on websites, in other XMPP accounts, or with ISP logs (e.g., time of activity on the Tor network).

A lot of people make a living doing this kind of analysis, from law enforcement and large corporations to individual researchers, including criminals.

Given this, it would be a shame to accidentally send an unencrypted message and let the server know the communication language of both users. To prevent an unencrypted message from being sent, you need to enable the corresponding feature in the messenger. For example, in Pidgin client with OTR encryption, it looks like this:

 

No log policy

When the server says that it never logs user data, it means that it logs it as long as it is necessary for the operation of the server. For example, the server must log the transmission of a message (even if encrypted), the IP address of the sender (even if it’s a Tor exit node), the time the message was sent, and other metadata. The server cannot delete this data until it has delivered the message to the recipient (or an error report if the message could not be delivered).

Privacy laws

Many countries have laws that require servers to delete such information as soon as possible after it is no longer needed to serve users. Also, in most countries, the server may not share this information with anyone, unless it is, again, necessary to serve users. Including law enforcement. Usually they need permission from a court or prosecutor, but in some countries a made up probable cause is sufficient for an officer to get this private information without any oversight.

The toughest privacy and security law in the world is General Data Protection Regulation (GDPR) in European Union [what is it] [full text].

Of course, any server can illegally share information about its users with ad networks, hackers, or law enforcement. Free services often make money this way, and are even designed to do so.

How an XMPP server can attack users

Leak your password

The server knows your password. Obviously, someone can log into your account and do anything you do. For example, write to another user by first establishing an encrypted OTR or OMEMO session with that user.

However, if you performed key authentication every peer’s device, the peer will see that he is now being written to by an unfamiliar not authenticated device. In this case, the peer should ask for authentication, as any educated user should do. When working with OMEMO, the parties should confirm the key fingerprint via another communication channel: fingerprint should be the same. With OTR, you can verify the fingerprint directly in the XMPP messenger or check if the other party knows a pre-agreed shared secret (some short word, number or character set):

Short and clear about authentication using OTR as an example:
https://otr.cypherpunks.ca/help/4.0.2/authenticate.php?lang=en

Impersonate any user (man-in-the-middle attack)

This attack will be noticed by users if they authenticated each other.

The XMPP server is responsible for routing traffic between user clients. XMPP server #1 in the first figure in the article routes traffic from Alice to XMPP server #2.
To perform a MiTM attack, malicious server #1 can delay this message (e.g., a request to create an encrypted session) from Alice. And resend this message to Bob, while impersonating Alice’s account. Her message will reach Bob, and Bob’s response will reach the fake Alice. The attacker copies Bob’s reply and sends it back to Alice, impersonating Bob’s account (the server doesn’t even need to know his password to do this).

For example, such an attack on users of a popular XMPP server was carried out by German law enforcement.

Manipulating data processed by server

If message encryption (OTR / OMEMO) is used, the server obviously cannot change message content. OTR and OMEMO also include author spoofing protection: the server cannot pass off a message from Alice as a message from someone else.

However, the server can simply deliberately fail to deliver the message or delay it slightly in transit. Or mess with presence: users who are not online will appear to be online, and vice versa; and will spoof the timestamp of their last available presence. Change statuses (e.g. “Away 12 min”) and indication of which client is used. Change roster content (buddy list). In short, petty stuff, only effective in combination with other dirty tricks.

Conclusion

Message encryption with key authentication is a must.

The European Union has great privacy laws: a popular EU server with a legal entity is in most situations better than a shady server from a third world country.

Watch out for strange behavior of the XMPP client and your conversation partner. Most of the time it is bugs and human error, but better safe than sorry.

By the way, you can host your own server anonymously. However, if you’re reading this article, you probably shouldn’t. It may look easy, but you need to be quite competent in system administration to take care of all the basic security measures. Otherwise, the server can become easy prey for hackers. There are many good free education courses on the Internet with practice for ‘homework’ and feedback from systems and/or teachers, if you like.