Discussion
Loading...

Post

  • About
  • Code of conduct
  • Privacy
  • Users
  • Instances
  • About Bonfire
David Chisnall (*Now with 50% more sarcasm!*)
@david_chisnall@infosec.exchange  ·  activity timestamp 4 days ago

@contrapunctus

I've posted at length about this before, so I didn't want to repeat myself, but (like this) it was deep in another thread. Here are some of the most important things:

In XMPP, your roster is stored on the server (in plaintext, because the server must be able to process it). The roster contains everyone in your contact list and everyone who has you in their contact list. This gives an attacker who compromises a server a complete dump of your communication graph, and a subset for a bunch of other people. This means that the number of servers you need to compromise to get the kind of metadata that the US uses to decide which people to kill is quite small.

Presence stanzas are unencrypted and broadcast. These contain your online status and propagate to everyone who has you in their contact list. Anyone on any of the servers in your contact list can see this and track your online status.

This makes it quite easy to do traffic analysis to find a subgraph of the communication network: Someone connects and then you see a flurry of messages and can immediately see which servers a person is connecting to. If people are using small servers, that's often enough to identify them even without compromising a server.

Every message you send, even with OMEMO, has plaintext to and from fields. This means anyone with access to either server knows who you're communicating with. This is also typically visible to passive monitoring. If two people are using the same server, it's easy to correlate incoming and outgoing traffic, especially since most servers are small (larger servers make the first problem worse: This is what I'm talking about when I say that making a distributed protocol secure is hard, you solve one problem and another gets worse). If two people are on different servers, you need to observe more, unless they are on single-user servers, in which case just watching one server is sufficient.

There are other issues, including some client-specific things about OMEMO downgrade attacks, but these are the most obvious ones.

But if, for example, you're thinking of setting up a union and don't want it to be easy for your employer to see who is involved in planning, XMPP is a bad choice. Just watching the traffic on the corporate WiFi makes it quite easy for them to see who is in the union chats.

  • Copy link
  • Flag this post
  • Block
pixelschubsi
@pixelschubsi@troet.cafe replied  ·  activity timestamp 3 days ago

@david_chisnall @contrapunctus
XMPP has *optional* unencrypted roster and presence broadcast. If those are a problem for your threat model, don't use them. You will still be able to keep a list of contacts on your local device and send OMEMO encrypted messages. Signal just doesn't have those features at all, so XMPP having them optionally in a bad shape shouldn't be a huge issue.

Regarding correlating traffic, that's possible with Signal as well. Not as easy, but still.

  • Copy link
  • Flag this comment
  • Block
pixelschubsi
@pixelschubsi@troet.cafe replied  ·  activity timestamp 3 days ago

@david_chisnall @contrapunctus
Regarding plain text to and from field: The to field is plain text in Signal as well, and the from field is only hidden (sealed sender) for some messages. Notably, the initial message between two parties can't have sender sealed, so every chat had at least one message with to and from field revealed. Further, Signals server can ask the client to resend a message without from field sealed and the client will just do as ask (see https://github.com/signalapp/Signal-Android/issues/13842)

  • Copy link
  • Flag this comment
  • Block
Log in

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances
Bonfire social · 1.0.0 no JS en
Automatic federation enabled
  • Explore
  • About
  • Members
  • Code of Conduct
Home
Login