infosechandbook
infosechandbook on Hacker News
... while the rest of the XMPP account remains on the XMPP server, inaccessible. There is no benefit as you can also store other primary IDs like phone numbers in your address book.
And the rest comes down to "continue a conversation with someone somewhere else" isn't so easy but the same pain as with any other messaging system, minus you may use the same XMPP client, plus you may need to search a while until you find an XMPP server that comes with the fitting XEPs for your use cases.
> At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO/PGP encryption.
How do you just "continue a conversation with someone somewhere else" when your XMPP server goes down?
Typically, you register an XMPP account on an XMPP server. If this server is offline, your account is unreachable as the account is managed by the XMPP server not by your client. Therefore, you can't use this account anymore. So you need to go to another XMPP server, register a new XMPP account, and then try to find your contacts again (which may be cached by your client or not). Finally, you have to convince "someone" that this is just you with another account on another server. There is also no verified E2EE anymore. If "someone" uses the same now-offline XMPP server, "someone" also needs to find another XMPP server.
How is this different from "when Signal goes down one uses a completely different instant messaging system", apart from using another client?
> That is why decentralized/federated is better
And we already explained (also several times) that XMPP is de-facto centralized as the vast majority of users only use a tiny number of XMPP servers hosted by an even smaller number of hosting companies. Which means: If one of these hosting companies blocks XMPP traffic (e.g., if a rogue state starts censoring) or one of these XMPP servers goes down, a huge part of XMPP users is affected.
> Signal admins too can ship you an app
Or I could just use my own Signal client since it is open-source and there are several working forks such as https://molly.im/. How do "Signal admins" (whoever this is) manipulate these open-source forks?
Instead of providing any proof or details, you just post one assumption after another to distract from obvious problems with current XMPP servers and clients. As soon as we debunk a myth, the next assumption comes up.
Another one is Kontalk, https://www.kontalk.org/.
Both XMPP clients require a phone number, and both present the phone number as a benefit in comparison with other XMPP clients without this requirement.
Once again, "I, as a tech-savvy person, can operate my highly-customized XMPP setup everywhere", while ignoring that most people do not run their own servers.
> they discourage people from using other clients
This was discussed numerous times various platforms and proven wrong.
> I can verify that my server isn't tracking users
As discussed before on this page, most XMPP users don't run their own XMPP server but use a public XMPP server on the internet. Nobody can check whether this public XMPP server tracks its users without accessing the server itself.
> all of your eggs in a centralized basket, both in terms of privacy and reliability.
So, do you assume the Signal network infrastructure consists of a single server?
> Do not know of a single XMPP client that requires a phone number
At least Quicksy (from the Conversations developer who bragged in a public video about copying WhatsApp/Signal) and Kontalk require a phone number. They even market the phone number requirement as a benefit in comparison with other XMPP clients.
> most people will tell you
I could just claim the opposite. Without any sources, it remains an assumption.
> Signal doesn't
Signal does. You wrote, you use Signal. Did you ever join a Signal group? There is a dialog when entering a group the first time.
Who defines "open standard" in the first place? There is no global definition for this.
> With Signal ... With XMPP ...
Another person just claimed comparing both is silly. There are already other comments addressing the rest of your statement.
> non-identifiable phone number ... random username
You compare distinct properties in your own statement. "non-identifiable" isn't the same as "random". If you want to get a random phone number, you can just buy any SIM card. Is this nitpicking? Maybe, but nitpicking is also including in dozens of "XMPP is better than Signal" statements in the comment section. There are already other comments addressing the rest of your statement.
Could you please add your statement to any other comments by XMPP proponents that state "XMPP is better than Signal because ..."?
Plus, could you also consider this for all of your own comparisons of XMPP and Signal?
> XMPP can be potentially used
Again, a lot of guessing and assumptions what could be in a perfect XMPP world, but nobody finds nowadays.
> with your custom XMPP deployment
This isn't a unique property of XMPP.
Where is this 1-to-1 comparison you demand in the OP's original article?
Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Signal wins as these security features aren't optional but enforced and more mature.
Privacy: This section in OP's article addresses distinct things to then somehow claim XMPP is private. Let's compare them:
XMPP is an open standard -> Doesn't this apply to Signal, too? Some developers claim not to track users -> Same applies to Signal. OMEMO adds security -> explained above, already in Signal. Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy. Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number, and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal. Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature. Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups. User is the only one deciding about/controlling their account and personal data (how can this be ensured if this data is exposed to the server and other users) -> Again a vague statement without any explanation. So Signal users can also decide about their data.
Then, OP's article suddenly ends without going into any details. The article finishes with "phone numbers, centralization bad; username, decentralization good." This isn't balanced at all.
> Signal admins, who control the server and ship an app to you which you can't really verify.
If we write exactly the same about XMPP, people immediately state, "XMPP clients and servers are open source, everybody can look at their code." So let's apply the same logic to Signal. If you don't want to apply this logic, then yes, we can't also verify if we connect to a malicious/manipulated XMPP server even if its source code is open. The same applies to apps. And Reproducible builds don't come with this guarantee, too.
Unfortunately, this seems to be the starting point of most discussions on XMPP. Somebody claims that XMPP solves all problems, and is secure and private. Or they present a highly-customized, non-default XMPP setup and compare this with an out-of-the-box competitor to show the superiority of their setup. We rarely see posts like your FAQ on the internet.
> ... or the worst
In case you refer to our article, we don't claim this. We recommend to self-host your XMPP server (if you can), or to migrate to alternatives instead of blindly trusting unknown entities on the internet. We are also not the police on the internet. People can choose what they want, including WhatsApp, Telegram, XMPP-based messengers, Signal, or whatever messenger they use.
> Let's try to promote more informative resources.
We will link to your FAQ. Thanks for providing more balanced content.
Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spoofed messages? Would be nice to see for the security community.
> What holds true in both systems is that if someone does this, it's detectable thanks to E2EE.
What also holds true: One system enforces E2EE; for the other system E2EE is optional, depends on the client, and while spoofing could be detected thanks to E2EE, all clients we checked didn't detect it (Gajim, Conversations, Psi+, Profanity).
Not in detail as the OP linked to another article. We commented on OP's other article, not on your joinjabber.org security FAQ.
> we were tired of FUD spread by articles like yours
Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way.
> Reality is more complex than a binary "is it secure?"
Indeed. Unfortunately, the vast majority of people assume security is binary. Back to OP's article where they look at some isolated properties to then declare a protocol secure.
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).
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.
As mentioned in the linked article, the behavior upon receiving an injected message is client specific. In any way, the injected message is somehow presented to the (non-technical) user who might then be targeted. We all know the same problem exists in the e-mail world.
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.
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.
See https://infosec-handbook.eu/articles/xmpp-aitm/#t5
TL;DR: XMPP clients can't distinguish between legitimate and injected messages, even if OMEMO is enabled. The XMPP client just displays injected messages as an unencrypted message from the sender.
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.
Signal enforces E2EE, you can't disable it. If XMPP supports E2EE depends on the XMPP clients and servers, so it isn't enforced and can be disabled. Server admins can even inject XMPP messages that look like coming from the legitimate sender. This is far from "secure as Signal."
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.
Adding legacy configuration to your OpenSSH config files can even result in a false sense of security (e.g., if the server/client just skip the legacy part and you think it adds some protection).
Newer options to secure OpenSSH are also missing (e.g., using U2F for 2FA, introduced in OpenSSH 8.2 (Feb 2020).
Everything shown in the article works with or without TLS enabled. It doesn't matter. The server-side party sees cleartext XMPP packets passing the server.
> all their tcpdump tricks fail
There are no "tricks" in the article. It is just capturing network traffic. The point here is that XMPP traffic isn't magically invisible to third parties that observe the network traffic as some people claim.
Indeed. One should mention upsides and downsides of a solution. In our opinion, many "use XMPP" comments only focus on the upsides but rarely mention any downsides. This is the primary reason for our article on some (not all) downsides of XMPP. We focus on easy-to-verify findings. However, we (and others) can't write an exhaustive list of pros and cons of all messengers.
> Were those arguments valid? Most of them drew attention to unrelated features. E.g., "Y requires your phone number; thus, users of Y can easily be tracked"; however, the situation isn't binary, and phone numbers weren't in our article in the first place.
The article clearly mentions that passwords are sent in cleartext to the server when the user sets/changes their password. It even clarifies that SCAM-SHA-1 won't help as hashing happens after cleartext password can be logged.
> loglevel: 5 (or “debug”) logs every single message and all activities mentioned above plus passwords in cleartext. Some XMPP proponents insisted that this isn’t true as XMPP servers use SCRAM-SHA-1 for password hashing. However, it doesn’t matter whether you enable or disable server-side password hashing as clients send new/changed passwords to XMPP servers in cleartext. The server logs the cleartext password before hashing it.
Server-side parties (e.g., the admin) can see the status information without adding somebody to the group. It is in cleartext, passing the server.
> The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP.
The article never states that these issues exclusively apply to XMPP. In our opinion, users should be aware of these downsides that might be obvious to technical people, but aren't obvious to others.
And no, not all the points apply equally to other services. Even if this would be the case, then should we just withhold downsides of XMPP because these downsides might also apply to unrelated communication protocols? This article is about XMPP, not about something else.
> Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use.
No, as stated in the article, you can't solve most problems with XMPP by enforcing E2EE in XMPP. This article is about XMPP, not about unrelated communication protocols that might have similar problems.
> Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering.
Ehm, no, again, this article lists verifiable downsides of XMPP. People should be aware of these downsides and decide on their own what they want to do. There is no need to call it "biased scaremongering."
> Full disclosure
Full disclosure: We aren't involved in any XMPP projects or any other projects related to instant messaging. No party paid for our article.
> I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in August 2018
We fully revised this and other articles as mentioned on our website. The article itself contains a note that it was republished.
We recommended alternatives back in 2019 when we published this article originally. Unfortunately, people then started to discuss why all of these alternatives were much worse according to them, distracting attention away from XMPP's downsides.