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

11–20 of 59 posts

Re: XMPP: Admin-in-the-middle

#11

Post by MattJ100 »

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 hide your IP from websites and services you use.

Common alternatives to XMPP that people may recommend include Signal and Matrix, but both certainly see your IP address just as easily.

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.

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. Again, not a problem with XMPP specifically.

Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering.

Full disclosure: I'm actively involved in various XMPP projects, including the XMPP Standards Foundation, Prosody and Snikket. Obviously I have a very keen interest in protocol design, secure online communication and the various available platforms/tools.

Re: XMPP: Admin-in-the-middle

#12

Post by southerntofu »

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 August 2018, see also: https://web.archive.org/web/20201208132104/https://infosec-h...

Re: XMPP: Admin-in-the-middle

#13

Post by ajconway »

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.

Hype and (related) money is what open messaging needs at the moment. XMPP is fine, it’s stable, extensible and generally works, but average users have never heard of it.

Re: XMPP: Admin-in-the-middle

#14

Post by southerntofu »

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, but i didn't try to reproduce yet. This would be worth investigating with wireshark and a couple of volunteers.

> not a problem with XMPP specifically.

There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. So your own server/admin will know when a client-to-server (c2s) connection is active, but in the XMPP ecosystem it's rather common for clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. Maybe something to investigate in the future.

Re: XMPP: Admin-in-the-middle

#16

Post by captainmuon »

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 of running your own server, you could just move the server completely into the client (and maybe have an external server only to buffer encrypted messages while you are offline). I wonder, is it possible to send P2P data from one cell phone to another nowadays? It used to be impossible to have any incoming open port, but I think in some circumstances you can use CGNAT hole punching, connect to other users on your carrier directly, or even use IPv6?

Re: XMPP: Admin-in-the-middle

#17

Post by LogonType10 »

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…

Would these leaks be solved by implementing a VPN at the router instead of the host?

Re: XMPP: Admin-in-the-middle

#18

Post by MattJ100 »

po1nt wrote: post #2

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

Basically all the issues listed in the article apply equally to Matrix, and most other communication platforms too.

There are some alternatives that overcome most of the issues with a "serverless" approach (hint: no practical communication protocol on the internet is ever truly serverless), such as Briar. However they generally have UI/UX and feature limitations that are impractical barriers to mass adoption.

If you're concerned that your communications may be specifically targeted, you should definitely consider carefully what solution meets your needs and security in the context of your threat model. Sometimes this might be self-hosting, or a pseudonymous XMPP account accessed via Tor, Signal or Matrix, or Briar, or something else.

What we need are good factual unbiased guides to inform people about the practical and security properties of various options. Unfortunately this article is not in that category.

Re: XMPP: Admin-in-the-middle

#19

Post by southerntofu »

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 newcomers can have a little backlog).

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 matrix, all data is replicated on all servers (which eats massive server resources, although newer implementations like conduit seem to improve on that) which greatly increases the possibilities for a bad actor to find their way to these conversations.

Re: XMPP: Admin-in-the-middle

#20

Post by topdancing »

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…

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

Post reply on HN