[infosechandbook]

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messen...?

Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for your account. What about all of the cleartext data and metadata that can be accessed by parties on the XMPP server, like the XMPP server admin, see https://infosec-handbook.eu/articles/xmpp-aitm/?

This logic implies that e-mail is also secure and privacy respecting.

[Communitivity]

XMPP supports additional security if the server and client support it, however some of the extension proposals (XEPs) are deferred or experimental. My hope that the Special Interest Group (SIG) for encryption pulls these together into new high-security client and high-security server profiles.

* https://xmpp.org/extensions/xep-0380.html - Explicit Message Encryption

* https://xmpp.org/extensions/xep-0429.html - Not a XEP really, but the formation of a SIG to explore a more robust end-to-end encryption support

* https://xmpp.org/extensions/xep-0420.html - Encrypting content specific to certain extensions

* https://xmpp.org/extensions/xep-0290.html - Digital signatures in XMPP

[southerntofu]

What would be your alternative? I agree there's a lot to research and improve in the XMPP ecosystem ( see also https://joinjabber.org/faqs/security/ ) but "admin in the middle" is not exactly a bug but a property of federated systems.

If your alternative is to use a centralized platform (which potentially requires a phone number to sign on) that's a trade-off i'm not willing to make. I'm personally very happy with my not-so-insecure pseudonymous communications (but always interested in constructive criticism).

[infosechandbook]

> What would be your alternative?

A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosystem.

Instead of claiming, "XYZ is secure because it supports TLS," articles should also mention what this means in terms of limitations (e.g., TLS protects data in transit, so server-side parties can still access the data) or defaults (e.g., only a subset of servers/clients support certain security features). While such things might be obvious to tech-savvy users, non-technical people don't understand this. They only read, "secure" and "private" and then assume, "Oh, it's secure and private, so I migrate to XYZ." In reality, "secure" and "private" aren't fixed states that you can identify by looking at some features.

[goodpoint]

XMPP leaks less metadata than alternative like Matrix, but it still very vulnerable to traffic correlation attacks from an external observer, server compromise and malicious server admin. Far from ideal.

Briar mitigates[1] these risks by using p2p messaging over Onion Services.

[1] mitigates: it's well known that even Tor cannot protect from correlation attack from a global observer but mounting such attack requires billions (see PRISM). Correlating traffic from/to an XMPP server is trivially easy for any person that has access to logs from a network device or can run a tcpdump on an hypervisor.

[MattJ100]

Traffic correlation attacks are very difficult to mitigate. Even Tor is not immune to this (see research such as [1], and the Tor project's own statements that the design is not resistant to analysis by a global network observer). Also Briar may be unsuitable for some use cases where you want to remain anonymous to people you communicate with[2].

Some research has been done into communication networks that are resistant to traffic analysis, such as Vuvuzela[3]. Unfortunately most such solutions requires permanent connectivity and bandwidth utilization, which makes them impractical for battery-powered mobile devices.

I'm firmly of the belief that no communication tool is suitable for all use-cases, but that we need to build open interoperable ecosystems that fulfil a range of needs, and help educate people about them.

[1]: https://nusenu.medium.com/the-growing-problem-of-malicious-r...

[2]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b...

[3]: https://vuvuzela.io/

[ezst]

tor isn't perfect, but if that's good-enough for your use-case, you can use/host a server over it: https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...

[MattJ100]

I already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983

I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files.

It's much more important to me that I know where my data is - or rather, know where it isn't. I'd rather have that than be forced to entrust my metadata to a third party such as WhatsApp/Facebook, Telegram or Signal.

Disclaimer: I'm an XMPP developer (as I know you know, but others may not).

[infosechandbook]

> I already responded to your "admin in the middle" article here

And we already responded here: https://news.ycombinator.com/item?id=29106376, and here: https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/, and somewhere on Reddit.

> I run my own XMPP server (Snikket) for my family

Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Can we agree that most non-technical XMPP users use a public XMPP server on the internet, where they might not know the individual or organization running the server? Where it remains unclear whether the XMPP server is set up and operated in a "secure" and "private" way? Where some XMPP server admins even fail to provide a privacy policy or try to hide their identity? Is this unique to XMPP? No, we never said this. Is this then a reason to ignore these issues? Also no. We should openly discuss pros and cons instead of highlighting isolated properties of a protocol that might be better in some situations than the same properties of a competitor.

[MattJ100]

> Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server?

Yes. The majority of people cannot, and will not ever, run their own server. However my ideal is that the remaining "10%" of people who can, do so. Just as I do for my non-technical family members. I believe that there should be a trust relationship between service operators and their users, whatever form that takes. I work daily to try and make self-hosting XMPP easy and accessible to more people, so we can increase this "10%" fraction.

For a similar perspective see: https://staltz.com/some-people-want-to-run-their-own-servers...

Of course using public XMPP services anonymously (burner accounts, randomly-generated username, connect via Tor/VPN, etc.) is a thing that many people also do, but I think that's a minority use-case (that should still be supported). Tools such as Briar also cover many such use-cases adequately or better.

[tialaramex]

I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church".

But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.

[jmnicolas]

Thanks for the laugh, you should write news title it would be fun!

Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

As the ex boss of NSA said "We Kill People Based on Metadata".

[tialaramex]

But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that?

The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than Signal.

XMPP encourages people to build clique servers, which fail a key security requirement "Don't Stand Out". The six other users of "Bob's 100% Preparedness Militia and True Patriots Server" may be quite sure Bob is trustworthy and won't rat on them, and maybe one of them only uses it to post funny GIFs of cats, but the loose metadata association between this group and a plot to kidnap a State Senator means all seven of them are targets anyway.

But if you try not to stand out by using a popular server, that server's operators have far more insight into you than Signal's server operators do. Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. I know, because I decrypted the message, but Signal does not. That's a bunch of heavy cryptographic lifting, but from their point of view it was worth it to improve privacy.

[zaik]

> Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that.

This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?

[tialaramex]

It does know the recipient it doesn't know the sender. They call this "Sealed sender" and it is enabled by default for your friends (but you can change who gets this facility).

So instead of a message from Steve to tialaramex, it's just a message to tialaramex. Well, duh, of course tialaramex gets messages, why else have message software?

My Signal client prepared some "stamps" which are good for one message to me. It gave Steve (and all my friends, or maybe only Steve, or maybe everybody except one troll, Signal can't tell and doesn't want to know) some of the stamps when sending them other things, and so Signal just sees the message has a stamp on it, no need to know who sent it.

[topdancing]

Your Signal client is at this moment logged into a Signal account on the Signal server. Sealed sender does nothing to protect against this - Signal knows that tialaramex is at that IP address.

The server fully aware where Steve is logged in from, and sees a message come from there to tialaramex. On top of even that: you then reply back, server sees a message going to Steve, going straight back to the IP address where it already knows he's logged in from.

Another thing people don't consider is that Signal's core server infra is hosted at AWS... so Amazon can also peek into both this network traffic and also dump out that it's your Signal account (ie. phone number) tied to that IP from the EC2 instance's memory.

These folks showed that this sealed sender stuff is broken last year: https://www.ndss-symposium.org/ndss-paper/improving-signals-... (and there's an acknowledgment from the Signal team on page 3 of the PDF).

[MattJ100]

They have a feature called "sealed sender"[1]. Your Signal client authenticates to a Signal service that verifies you, and then signs and issues a certificate that you can use to vouch for your identity.

Then, you can encrypt this certificate as part of your message. Then ask Signal to deliver your message to the recipient. The Signal server won't be able to tell the recipient the account that the message is from, but after the recipient decrypts the message they will see the signed certificate and know it was you.

The problem with this is, Signal is centralized and they see the both the IP address (and other metadata) when you contact them to obtain the certificate and they they also see the IP address you send the message from. Correlation between the two Signal-operated services would reveal your identity. Unfortunately we, as users, have no way to know that this is not happening.

[1]: https://signal.org/blog/sealed-sender/

[rakoo]

At the time of reception, the Signal server knew that there was a message from a certain IP to a certain recipient. If the message was put in the queue, the originating IP was forgotten. Once the message is delivered, the recipient is forgotten.

EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal. As neighbor comments have said it still knows at that moment that a message from you is sent.

[ezst]

> EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal.

For a centralized service like Signal, your IP doesn't matter, they own your account, literally. You can randomize it as much as you like, and your peers may too, in the end it will not hide from them who sent a message to whom and when.

[infosechandbook]

> Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"?

And how about looking at more than just an isolated property of a competitor?

> As the ex boss of NSA said "We Kill People Based on Metadata".

XMPP servers are a gold mine when it comes to metadata.

[zaik]

> It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved.

Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. How many of your contacts who use Signal used their real phone number?

> XMPP servers are a gold mine when it comes to metadata.

Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.

[infosechandbook]

> How many of your contacts who use Signal used their real phone number?

Most of them; however, there is no obligation to provide any personal data when registering a SIM card in my country. Even if providing personal data would be mandatory and if we assume that telcom providers track us all the time, then it doesn't mean that this data is accessible to the organization behind an instant messaging service.

> Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.

This ignores that Signal and XMPP don't process the same amount of metadata in the first place, and the de-facto centralization of the XMPP network (also stated in our article -> the majority of XMPP users only uses a small number of public XMPP instances, and these XMPP instances are hosted by a tiny number of companies in mainly three countries on this planet).

[rakoo]

> Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place.

I believe the real reason Signal requires a phone number is that it is a pretty good anti-spam filter

[tptacek]

You think you're making an argument against Signal, but you're in fact making the argument for it. The reason Signal deals in your phone number is precisely to keep them from managing databases of metadata about who's talking to who; the phone numbers keeps the social graph on the clientside.

Go look at RFC6121 Section 2 for one example of this. The point of Signal's design is that the server can't facilitate this kind of transaction, because it's unsafe for the server to keep that data in plaintext.

[singpolyma3]

> Nobody show them Signal or their head might explode.

Most popular XMPP encryption is literally signalprotocol, so I'm pretty sure the community is aware :)

[Andrew_nenakhov]

Hard to believe someone compares proprietary centralised silo service like Signal to an open federated protocol.

[zaik]

You mention IP address, location based on IP addresses, timestamps, bytes transmitted and number of packets as metadata which is disclosed to the server admin. What alternative messenger do you suggest which does not disclose this metadata to the server operator?

[infosechandbook]

> disclosed to the server admin

Please read the article before and after these items. The first finding isn't about the server admin but about external parties such as law enforcement (not the user, not the admin). The reason for this finding: Some people claim XMPP traffic can't be censored as nobody can identify XMPP traffic from outside. This isn't true as this finding shows. You can easily detect and filter XMPP coming through network devices.

This finding might be the most unsurprising one in the article from a technical perspective, and we are well aware of this.