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

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

Post reply on HN
Print view View original

41–50 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#41

Post by southerntofu »

yosamino wrote: post #13
MattJ100 wrote: post #10

Earlier quoted context omitted.

Movim is a social-oriented XMPP client, so yes, it needs to log in to your account. You don't have to use the mov.im instance - in an ideal world your own server can run a copy of Movim, but you can also self-host, or even run it locally on your system. This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and…

> This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. So that I can do something along the lines of "Log in with XMPP" and then my client asks me "hey do you wanna allow movim.eu to access foo/do bar on your behalf" ? That sounds very useful. Sharing my password lik…

This is already possible! https://xmpp.org/extensions/xep-0070.html

Re: XMPP: The secure communication protocol that respects privacy

#42

Post by emptysongglass »

southerntofu wrote: post #30
gefhfffh wrote: post #15

Earlier quoted context omitted.

How would it be even possible to build Matrix, as it is today, on XMPP? And, more importantly, why would you want to do that? What would be the benefit if that was done?

> How would it be even possible to build Matrix, as it is today, on XMPP? And, more importantly, why would you want to do that? Glad you asked! There's two main components to Matrix: the client-to-server (c2s) and server-to-server (s2s) APIs. The c2s API on matrix is of little to no value and could have been implemented as an HTTP API to XMPP servers: the way this is done in the XMPP ecosystem is with BOSH so we wrap…

As someone who selfhosts Matrix and XMPP (thanks, Snikket!) I don't understand why Matrix is so terrifically burdensome to maintain if it is indeed competing. I've had three Matrix deployments all go wonky in various ways. I'm finally fed up with the Python implementation and hoping that the Rust implementation will solve all my woes.

XMPP clients running on a tiny VPS just feel very fast in comparison to Matrix clients running through a much larger VPS. Rooms still take ages to join whereas Snikket joins almost instantly. I've spent truly astounding amounts of time debugging Matrix's Postgres database, to video calls to Discord bridges. Snikket just keeps on ticking no matter what I throw at it.

It's starting to feel like the spec itself might be to blame but I welcome the input of experts, such as yourself.

Re: XMPP: The secure communication protocol that respects privacy

#43

Post by jmnicolas »

tialaramex wrote: post #39
infosechandbook wrote: post #28

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messen... ? Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for…

I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church". But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.

Thanks for the laugh, you should write news title it would be fun!

Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

As the ex boss of NSA said "We Kill People Based on Metadata".

Re: XMPP: The secure communication protocol that respects privacy

#44

Post by southerntofu »

Thanks for the article! Just to nitpick:

> Moreover, the protocol has been audited by a third party.

Some implementations have been audited, unfortunately far from all! There's a lot of things to audit and/or improve related to privacy and security in the XMPP ecosystem: i would personally recommend to read this FAQ: https://joinjabber.org/faqs/security/

> Also, on this page, you can track the progress of OMEMO integration in XMPP clients (applications)

This is true, but based on estimated progress not something measured by a test suite. For example poezio is marked 100% but i keep having OMEMO problems with it (not blaming the poor poezio-omemo maintainer who's working on it alone mostly).

> Only the nickname is displayed if you participate in a group chat or a channel (here, the XMPP extension called MUC, the acronym for Multi-User Chat, is used).

Except for the room operators! The MUC server admins have access to all addresses, as well as room admins. Also, some rooms are public in which case everyone can read everyone's address (like a mailing list).

Re: XMPP: The secure communication protocol that respects privacy

#45

Post by zaik »

infosechandbook wrote: post #33
f1refly wrote: post #23

Earlier quoted context omitted.

XMPP is as secure as Signal nowadays, it implements the same encryption scheme and is still completely federated: https://conversations.im/omemo/ Omemo is a relatively recent effort though and many people still remember the days when gpg and otr where the sad state of the art in the xmpp world.

> XMPP is as secure as Signal nowadays, it implements the same encryption scheme 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."

> Server admins can even inject XMPP messages that look like coming from the legitimate sender.

How should that be possible if OMEMO is enabled (which is the default in more modern clients)?

Re: XMPP: The secure communication protocol that respects privacy

#46

Post by MattJ100 »

southerntofu wrote: post #41
yosamino wrote: post #13

Earlier quoted context omitted.

> This year I'm also going to be working on account access delegation for XMPP as part of a funded project, resulting in implementation in Prosody (server software) and publishing/updating related standards. So that I can do something along the lines of "Log in with XMPP" and then my client asks me "hey do you wanna allow movim.eu to access foo/do bar on your behalf" ? That sounds very useful. Sharing my password lik…

This is already possible! https://xmpp.org/extensions/xep-0070.html

That's slightly different. XEP-0070 is about allowing someone to verify that you own a given XMPP address. That is indeed often all you need for a "Log in with XMPP" functionality. Just how many sites allow you to log in with an email + verification link today.

However it does not grant someone the ability to connect to your account and perform any actions. Movim is an XMPP client. It interacts with the XMPP network as you, not as a third-party. That's very different to what XEP-0070 is for.

Currently the only practical way to allow someone access to your XMPP account is to give them your credentials. But if you do that, there's no way to restrict, monitor or revoke their access (apart from changing your password - something they would also be able to do!).

Many XMPP server implementations already implement some of the building blocks for something better (e.g. Prosody and ejabberd both support OAuth in some form already). But there are a number of important missing pieces before we can get it usable and adopted, and that's what I will be focusing on this year.

Again, in Movim's case it's fully open-source. You can self-host it or run it on your laptop, so you're never forced to hand over your credentials to any third party today. But many people would find a mechanism to grant a third-party limited access to their account an acceptable solution, so they can use Movim instances hosted by others.

Re: XMPP: The secure communication protocol that respects privacy

#47

Post by tialaramex »

southerntofu wrote: post #38
Semaphor wrote: post #29

Earlier quoted context omitted.

> just work™ YMMV™ We have yet to manage not getting any OMEMO issues in a 2 users, 5 clients situation (2 Conversations on android, 1 Gajim on win, 2 Pidgin on linux)

If you care to elaborate, i'm sure that'll be of interest to maintainers. Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

> Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.

Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you thought it did.

Here's my unsolicited recommendation: Block Pidgin. Not just Pidgin, any time the XMPP community finds itself having to explain that oops, that client doesn't work so good, please use a different one, just block the client, permanently instead, from all popular and well known servers, tell anybody who will listen that's not a real XMPP client, not any more.

Any time the community just can't bring itself to block a client, cross off the features that don't work across the ecosystem due to that client. Those aren't really XMPP features any more since they exist only for some users and the community is apparently OK with that.

And each year, stand back and look at the resulting two steps forward three steps back juddering "Progress" and reconsider - was this the way to get where you wanted to go? Or are you all wasting your time on an exercise that would be easier done a different way.

Re: XMPP: The secure communication protocol that respects privacy

#48

Post by infosechandbook »

southerntofu wrote: post #40
infosechandbook wrote: post #28

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messen... ? Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for…

What would be your alternative? I agree there's a lot to research and improve in the XMPP ecosystem ( see also https://joinjabber.org/faqs/security/ ) but "admin in the middle" is not exactly a bug but a property of federated systems. If your alternative is to use a centralized platform (which potentially requires a phone number to sign on) that's a trade-off i'm not willing to make. I'm personally very happy with my…

> What would be your alternative?

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.

Re: XMPP: The secure communication protocol that respects privacy

#49

Post by infosechandbook »

zaik wrote: post #45
infosechandbook wrote: post #33

Earlier quoted context omitted.

> XMPP is as secure as Signal nowadays, it implements the same encryption scheme 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."

> Server admins can even inject XMPP messages that look like coming from the legitimate sender. How should that be possible if OMEMO is enabled (which is the default in more modern clients)?

> How should that be possible if OMEMO is enabled (which is the default in more modern clients)?

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.

Re: XMPP: The secure communication protocol that respects privacy

#50

Post by rakoo »

folex wrote: post #25

How about XMPP performance on low-performance networks like mobile ones? I believe poor networking performance was one of the reasons XMPP had to be customised in WhatsApp and overall didn't become as widely used as I'd like it to be :) Is it still the case? Or was that problem addressed at standard level somehow?

That is a situation documented by people years ago, and has been wrong for years. See https://gultsch.de/xmpp_2016.html. Unfortunately the legend lives on because "it doesn't work" is a better soundbite than "it works"
Post reply on HN