XMPP: Admin-in-the-middle • Hacker News Board

Re: XMPP: Admin-in-the-middle

#41

Post by gefhfff » Thu, Nov 04, 2021, 12:14 PM UTC

topdancing wrote: post #20

lmm wrote: post #10

Earlier quoted context omitted.

I think that bit of history shows what a false idol extensibility is. 20 years of extension and improvement has resulted in a chat system that is still staggeringly worse in practice than its competitors of 20 years ago. (Seriously, XMPP is still worse than AIM for actual day-to-day use). Look at XML vs JSON for another example. A simple standard that has no improvement path except completely replacing it turns out t…

> Seriously, XMPP is still worse than AIM for actual day-to-day use Have you actually tried the modern clients like Conversations/Dino? I've been running a private XMPP server for friends for the past couple of years and the only way to describe it is rock-solid.

Have you actually tried any alternatives at all?

Even Matrix with Element (which used to have quite a few issues with slowness and encryption), works way better these days

Not to mention any widely used centralized messenger...

Re: XMPP: Admin-in-the-middle

#42

Post by gefhfff » Thu, Nov 04, 2021, 12:20 PM UTC

zaik wrote: post #40

gefhfff wrote: post #35

Earlier quoted context omitted.

Matrix

Why should I use Matrix over XMPP? All the problems mentioned in this article also apply to Matrix.

Matrix has introduced some really neat innovations compared to XMPP:

- decentralized conversations instead of centralized ones

- MEGOLM

- Cross Signing

- monolithic protocol (i.e. one true way of doing things officially)

- easy sync of (encrypted) history between sessions

These are reasons why people use Matrix and not because of misinformation about how private it is

Also: afaik not everything applies to Matrix, e.g. a widely used server logging passwords or a server being able to manipulate chat rooms that extensively

Re: XMPP: Admin-in-the-middle

#43

Post by megous » Thu, Nov 04, 2021, 12:20 PM UTC

southerntofu wrote: post #36

Andrew_nenakhov wrote: post #34

Earlier quoted context omitted.

Strange criticism. Advertising presence information is the _goal_ of XMPP protocol. The "P" in XMPP stands for Presence.

Indeed! However, some things have changed since XMPP initially came out. For example, Message Archive Management (and equivalents in the PubSub/MIX specs) has been introduced so that messages can be stored reliably, reducing the need for presence. Multi-client usage has also grown, especially with mobile computers ("smartphones") with Internet access everywhere. Then, we now know and have proof that metadata leaks ar…

Unless the protocol is connectionless, the server will always know at least the user's online status.

I have to use Slack for work, and the way I solve this is to have my client not send typing notifications, and have the client running on my server and repeatedly sending activity notifications all the time, so I always appear online and present to Slack servers.

I can prevent Slack from knowing when I'm really connected only by being connected all the time and always pinging my activity status in periodic fashion 24/7, so that from PoV of the server it's not possible to determine anything about my actual activity or online status on my workstation, because there's no relation to real-life status.

Re: XMPP: Admin-in-the-middle

#44

Post by rhn_mk1 » Thu, Nov 04, 2021, 12:21 PM UTC

MattJ100 wrote: post #28

rhn_mk1 wrote: post #26

Earlier quoted context omitted.

> XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication. There are plenty of authentication protocols that don't send passwords in cleartext. WPA would b…

I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user…

I see the distinction, but when I use public key cryptography, the keys are not symmetrical, and the server never sees my secret.

Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange.

Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password to unlock the private key, but only send the public key?

Re: XMPP: Admin-in-the-middle

#45

Post by megous » Thu, Nov 04, 2021, 12:21 PM UTC

Andrew_nenakhov wrote: post #39

southerntofu wrote: post #36

Earlier quoted context omitted.

Indeed! However, some things have changed since XMPP initially came out. For example, Message Archive Management (and equivalents in the PubSub/MIX specs) has been introduced so that messages can be stored reliably, reducing the need for presence. Multi-client usage has also grown, especially with mobile computers ("smartphones") with Internet access everywhere. Then, we now know and have proof that metadata leaks ar…

It is quite possible not to send presence information at all. I'll say more, we're working on an 'omnipresence' protocol that will advertise only the desired status to the external contacts, and will not leak per-device presences. This Presence thing works well for always connected clients (desktop), but becomes a huge problem on clients that can't be always connected (iOS ones).

Desktop is not always connected. People turn it off, or suspend it to save on electricity bills.

Re: XMPP: Admin-in-the-middle

#46

Post by infosechandbook » Thu, Nov 04, 2021, 12:24 PM UTC

southerntofu wrote: post #12

These points are good to know, but as others pointed out they apply to email, Matrix, ActivityPub and other federated protocols. I believe we have published a rather comprehensive security/privacy FAQ here: https://joinjabber.org/faqs/security/ Let me know if you find some information missing in there! PS: I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in Au…

Hi, authors here.

> 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.

Re: XMPP: Admin-in-the-middle

#47

Post by megous » Thu, Nov 04, 2021, 12:27 PM UTC

rhn_mk1 wrote: post #44

MattJ100 wrote: post #28

Earlier quoted context omitted.

I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user…

I see the distinction, but when I use public key cryptography, the keys are not symmetrical, and the server never sees my secret. Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange. Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password t…

Yes. You'd probably want to derive your private key from the password, so that you don't have to store anything and use this method portably on multiple computers. But there's no need to ever send a password to the server, even when setting/changing it.

In theory... I don't know if there's any established auth method like this, that would eg. generate ed25519 secret key from a password, and used pubkey from it to send to the server when creating account or changing passwords and server using some challenge response, to authenticate users.

Re: XMPP: Admin-in-the-middle

#48

Post by MattJ100 » Thu, Nov 04, 2021, 12:27 PM UTC

GTP wrote: post #33

MattJ100 wrote: post #21

Earlier quoted context omitted.

> There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are f…

>They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join) But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct? Edit: formatti…

Valid question, not sure why the downvotes. You're right, the server can modify the contact list (and this is used extensively within organizations, and in Snikket to ensure family members can see each other by default).

But this isn't the cause for concern here - if the server is malicious it can broadcast this info without the need to modify your contact list. This again is independent of protocol - if someone wants to log or share the times and durations you are actively connected to their server, they can do so quite easily. It doesn't require XMPP.

Re: XMPP: Admin-in-the-middle

#49

Post by infosechandbook » Thu, Nov 04, 2021, 12:39 PM UTC

MattJ100 wrote: post #11

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. Half the article is dedicated to obsessing that the server can see your IP address. This is true of every internet service, and is how the internet works. Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to h…

Hi, authors here (Again, as we already have had the pleasure a while ago).

> 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.

Re: XMPP: Admin-in-the-middle

#50

Post by infosechandbook » Thu, Nov 04, 2021, 12:41 PM UTC

GTP wrote: post #33

MattJ100 wrote: post #21

Earlier quoted context omitted.

> There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are f…

>They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join) But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct? Edit: formatti…

> the user isn't really in control of who can see this information

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.