Matrix

One question I'm often asked is what metadata Matrix leaks. It does get tiring answering the same questions, so I'm creating an article I can simply link to any time someone asks.

I am on record many times saying Matrix leaks metadata. However, one thing that many people fail to understand is exactly what Matrix leaks, and why.

Note: For the purposes of this article, it's assumed users are communicating using end-to-end encryption (E2EE). In non-E2EE rooms, you can expect everything mentioned here to be leaked, as well as actual message contents.

What is a metadata leak?

Metadata leaks are when your messaging app includes metadata in a way that's not encrypted end-to-end. This includes the dates and times you send messages, who you send them to, how frequently you send messages, and more. Many messengers allow you to set status messages and profile pictures. These are not encrypted, and are thus leaked. The issue with metadata leaks is they can fairly easily reveal sensitive information, even when you don't expect them to.

What metadata does Matrix leak?

Matrix supports end-to-end encryption (E2EE). This protects the contents of messages, such that nobody can read them except the intended recipients. E2EE can be enabled manually in Matrix rooms, but is also enabled by default in 1:1 chats (DMs). Some clients may not enable E2EE by default, so you should always verify whether messages are sent E2EE.

Matrix's E2EE does not, however, encrypt everything. The following information is not encrypted:

• Message senders
  • Message senders are never encrypted
• Session/device IDs
  • Due to Matrix's design, encrypting this would break verification
• Message timestamps
  • It's impossible to prevent timestamps from leaking, since the server can simply note when an event is received anyway
• Room members (join/leave/invite events)
  • Join/leave/invite and other room events are never encrypted
• Message edit events
  • While contents are not leaked, an attacker can know when messages are edited
• Message reactions
  • Reactions are never encrypted
• Read receipts
  • Read receipts are never encrypted
• Nicknames
  • Nicknames are never encrypted
• Profile pictures
  • Profile pictures are never encrypted

To demonstrate some examples of these leaks, I have made some examples available: https://snippets.serpentsec.1337.cx/matrix-metadata-leaks

Who can view metadata?

The following metadata can be seen by any homeserver with at least 1 member in an E2EE room:

• Message senders
• Session/device IDs
• Message timestamps
• Room members (join/leave/invite events)
• Message edit events
• Message reactions
• Read receipts
• Room-specific nicknames
• Room-specific profile pictures

The following information is publicly available:

• Global nicknames
  • Matrix allows setting room-specific nicknames, which are less visible to attackers
• Profile pictures
  • Matrix allows setting room-specific profile pictures, which are less visible to attackers

Examples

• A room has 2 members, both from homeserver1.example.com. Any attacker with access to homeserver1.example.com can see metadata from that room. This includes homeserver admins, as well as anyone who manages to compromise the homeserver.
• A room has 2 members, one from homeserver1.example.com, and another from homeserver2.example.com. Any attacker with access to homeserver1.example.com or homeserver2.example.com can see metadata from that room. This includes homeserver admins, as well as anyone who manages to compromise one (or more) of the homeservers.
• I think you get the idea...

Why does Matrix leak metadata?

Federated networks are naturally more vulnerable to metadata leaks than P2P or centralized networks. These leaks can be fixed, at the expense of increased complexity of the protocol (thus making it more vulnerable to faulty implementations). Matrix's failure to prevent these leaks is necessary for proper functioning of the protocol.

Some metadata must be leaked due to features Matrix provides. For example, Matrix's message verification requires knowing which user and device sent a message (to know which key to verify with). In other cases (such as global profile pictures and nicknames), the information is considered public anyway, and therefore has no need to be encrypted. Matrix's failure to prevent these leaks is a triviality.

Some metadata leaks are accepted for performance requirements. For example, message reactions and read receipts might not be encrypted because Matrix's E2EE is slower than normal (non-E2EE) messaging. Encrypting reactions and read receipts could provide a painful user experience (UX). Matrix's failure to prevent these leaks is a design feature.

Some metadata leaks are simply a matter of the protocol's failure to consider them. For example, room-specific nicknames, room-specific profile pictures, and message edit events could all be encrypted without breaking the protocol. Matrix's failure to prevent these leaks is a design flaw.

Note: Though edit events are leaked, message contents are not.

All original non-code/non-software content is committed to the public domain, except where otherwise explicitly stated. Code/software is licensed under the BSD 3-clause license, except where otherwise explicitly stated. Content not originally created by Serpent Security may be subject to separate licensing terms.

‏Source serpentsec.1337.cx