Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMPP: Admin-in-the-middle

infosec-handbook.eu

Post reply on HN
Print view View original

31–40 of 59 posts

Re: XMPP: Admin-in-the-middle

#31

Post by yosamino »

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…

> All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged.

Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php

Thanks for the hint!

Re: XMPP: Admin-in-the-middle

#32

Post by upofadown »

This article triggers one of my current pet peeves. It treats privacy and anonymity as more or less the same thing. Anonymity is a sort of privacy related to identity, but it is not required that you are anonymous to have privacy. Everyone can know that I am sending encrypted messages to other people but those messages are still private. Anonymity should be discussed as a special case.

Having said that, XMPP can be quite anonymous in practice. There are public XMPP servers running on hidden services. XMPP servers do not insist that you give them any personal information at all. In particular they normally do not require a phone number.

Re: XMPP: Admin-in-the-middle

#33

Post by GTP »

MattJ100 wrote: post #21
southerntofu wrote: post #14

Earlier quoted context omitted.

> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use. So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP…

> 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: formatting

Re: XMPP: Admin-in-the-middle

#34

Post by Andrew_nenakhov »

southerntofu wrote: post #14
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…

> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use. So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP…

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

Re: XMPP: Admin-in-the-middle

#35

Post by gefhfff »

underatree wrote: post #29

Is there a better alternative that meets the following constraints: * standards based: i.e. it has demonstrated commitment to openness and universality * multi stakeholder: i.e. it has momentum * can self host: i.e. power can reside with communities * has clients that support encrypted video chat: i.e. I can use it today. XMPP does that.

Matrix

Re: XMPP: Admin-in-the-middle

#36

Post by southerntofu »

Andrew_nenakhov wrote: post #34
southerntofu wrote: post #14

Earlier quoted context omitted.

> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use. So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP…

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 are used to actually harm people and that presence information can be used to establish correlations between several identities.

To be clear, I'm not arguing against presence being supported on a protocol level. However, i believe the protocol and clients/servers should support the usecase where presence information should not be leaked: that people see a message when i send it is fine, but that they know when my computer is online/offline, or when i'm "away" is way too much metadata leak for a privacy-conscious usecase.

My favorite way to deal with that would be to have a "private browsing" mode on IM clients. So that you could turn on/off privacy settings globally with a single switch. I'm guessing a lot of people would choose the "private" mode if prompted for it on first run. I know i would :)

Re: XMPP: Admin-in-the-middle

#37

Post by gefhfff »

southerntofu wrote: post #19
po1nt wrote: post #2

I wanted to change Matrix for XMPP, now I have one less reason to do so.

In matrix, not only can your homeserver usually impersonate you, but most information/history in rooms is considered public and archived forever. I haven't followed recently if there were mitigations on this topic, but that was historically one of the reasons many activists stuck with IRC/XMPP who support ephemeral discussions and/or an explicit data retention policies (eg. keep the latest 20 messages in this room so…

> who support ephemeral discussions and/or an explicit data retention policies

Matrix's variant of that: https://brendan.abolivier.bzh/matrix-retention-policies/

> In case that wasn't clear, in the XMPP model, the backlog for a room is kept on the room's server, not on every individual home server. In

Which makes your history dependent on a plethora of different servers. Result: very bad usability

> replicated on all servers

No, this is misleading. It is replicated between servers that have users participating in the conversation, i.e. know the conversation anyways

> which eats massive server resources

I'd like to have a source for that. To my knowledge Matrix cryptographically verifying actions between servers (prohibiting various bad actions due to the decentralized nature of rooms in Matrix) and the implied DAG is really what needs resources

Re: XMPP: Admin-in-the-middle

#38

Post by gefhfff »

edhelas wrote: post #8
rvz wrote: post #6

So the hype around XMPP is no better than Matrix then. Oh dear. Going to keep using Matrix then.

So the hype around Matrix is no better than XMPP then. Oh dear. Going to keep using the IETF XMPP Standard then.

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

Re: XMPP: Admin-in-the-middle

#39

Post by Andrew_nenakhov »

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…

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

Re: XMPP: Admin-in-the-middle

#40

Post by zaik »

gefhfff wrote: post #35
underatree wrote: post #29

Is there a better alternative that meets the following constraints: * standards based: i.e. it has demonstrated commitment to openness and universality * multi stakeholder: i.e. it has momentum * can self host: i.e. power can reside with communities * has clients that support encrypted video chat: i.e. I can use it today. XMPP does that.

Matrix

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