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

21–30 of 59 posts

Re: XMPP: Admin-in-the-middle

#21

Post by MattJ100 »

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…

> 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 far less common than they used to be, because they are growing irrelevant.

Advertising online status to the whole world is what WhatsApp does ( https://news.ycombinator.com/item?id=26809770 ).

Re: XMPP: Admin-in-the-middle

#22

Post by ptman »

topdancing wrote: post #9
rvz wrote: post #6

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

If there's anything that's overhyped these days, it's Matrix. https://news.ycombinator.com/item?id=27557113 was so brilliant at capturing my own thoughts/concerns on it.

Those parts of matrix needed for interop need to go through the spec change proposal process to land in the spec. But namespacing is used extensively. The spec reserves the 'm.' prefix, e.g. 'm.text', but everyone is encouraged to extend using reverse dns namespacing, e.g. 'com.ycombinator.news.our.extension'.

Re: XMPP: Admin-in-the-middle

#23

Post by southerntofu »

lmm wrote: post #10
topdancing wrote: post #9

Earlier quoted context omitted.

If there's anything that's overhyped these days, it's Matrix. https://news.ycombinator.com/item?id=27557113 was so brilliant at capturing my own thoughts/concerns on it.

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…

> XMPP is still worse than AIM for actual day-to-day use

Care to elaborate? I used AIM back in the day and i have a much more pleasant and varied experience on modern XMPP, which supports many gateways to the networks i care for (including mobile phone like skype was doing! [0]).

> XML vs JSON

And yet the people who claimed XML was too complex have since then reimplemented the XML features into JSON, such as JSON schemas which are key to federated protocols (eg. ActivityPub) built on top of JSON message passing.

[0] https://jmp.chat/

Re: XMPP: Admin-in-the-middle

#24

Post by MattJ100 »

captainmuon wrote: post #16

I was not really expecting XMPP to do anything else by default, to be honest. If you want end-to-end encryption, the hard thing is to do the initial key exchange in a way that the server can't just MITM. It is extremely rare that somebody compares the "security numbers" of services like Signal to be sure there is no interposer. One solution might be to do key exchange by a completely separate third party. Or, instead…

The problem with pure peer-to-peer communication is that it is unreliable due to IP address changes and NATs, requires you to always be online (or at least both be online simultaneously) and also exposes your social graph to your ISP and any other intermediary on the network path.

Some of these can be fixed by adding servers into the mix (such as discovery/rendezvous servers, or Tor), but that doesn't solve everything.

Re: XMPP: Admin-in-the-middle

#25

Post by Semaphor »

ptman wrote: post #15
Semaphor wrote: post #5

Earlier quoted context omitted.

If only Matrix had nice clients like Conversation or Gajim instead of all those mIRC and Discord look-alikes.

Which matrix clients have you tried? Fluffychat?

I tried elements and looked at all the screenshots of non-alpha clients on https://matrix.org/clients/

Fluffychat would be okay for mobile. But that still leaves me without a primary client on my Windows PC.

Re: XMPP: Admin-in-the-middle

#26

Post by rhn_mk1 »

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…

> 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 be rather useless if that happened, for example. Granted, the server operator can impersonate anyone they want already, but password leaks are a thing.

Server-side contact handling is independent of end-to-end ecryption, and doesn't need to be plaintext either.

Pretty much the only excusable things here are what's related to IP.

Re: XMPP: Admin-in-the-middle

#27

Post by southerntofu »

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…

> and typically groups that you join

So more or less to the entire world if you join public chats. Even if you use different nicknames, occupant-id (used for message edits) may be used to track your presence across rooms.

> Advertising online status to the whole world is what WhatsApp does

If we're pointing the finger, i'd recommend reading this document about what Signal does wrong in terms of privacy and security. It's overall a good read of what not to do in private messenger UX:

https://north-shore.info/wp-content/uploads/2019/06/signalfa...

Re: XMPP: Admin-in-the-middle

#28

Post by MattJ100 »

rhn_mk1 wrote: post #26
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…

> 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 selects their own password. This step is where the password is sent (once) to the server, upon which it is hashed and stored. That step doesn't happen in WPA, however the owner of the access point does have to securely transmit the password to the clients somehow.

Re: XMPP: Admin-in-the-middle

#29

Post by underatree »

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.

Re: XMPP: Admin-in-the-middle

#30

Post by MayeulC »

captainmuon wrote: post #16

I was not really expecting XMPP to do anything else by default, to be honest. If you want end-to-end encryption, the hard thing is to do the initial key exchange in a way that the server can't just MITM. It is extremely rare that somebody compares the "security numbers" of services like Signal to be sure there is no interposer. One solution might be to do key exchange by a completely separate third party. Or, instead…

Use a STUN server to assist with NAT traversal. Some DHT swarms can also assist with that.

Or use a VPN or VPN-like network, like TOR, yggdrasil, IPFS p2p, etc. Some are explicitly designed for that kind of use, and can form a mesh network with peers that are physically close.

Unfortunately, for yggdrasil that means mostly Apple's Airdrop, though that should be possible with the more recent wifi NAN "neighbour area network" (wifi aware) and P2P.

Post reply on HN