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

81–90 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#81

Post by davecridland »

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?

XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use.

WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone.

Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think.

So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile.

To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.

Re: XMPP: The secure communication protocol that respects privacy

#82

Post by southerntofu »

infosechandbook wrote: post #79
southerntofu wrote: post #75

Earlier quoted context omitted.

Quoted post unavailable.

> Have you read the joinjabber.org security FAQ i linked? Not in detail as the OP linked to another article. We commented on OP's other article, not on your joinjabber.org security FAQ. > we were tired of FUD spread by articles like yours Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way. > Reality is more complex than a binary "is it secure?" Indeed. Unfortunat…

> Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way.

Yes, but there is no fearmongering involved. I'm part of the people who appreciated your article for the technical arguments, but i strongly dislike the fearmongering vibe (unless we do the same with every other protocol which could be fun). I actually started to write that FAQ precisely because i was tired of the script kiddies on both sides claiming XMPP is either the best or the worst and this or that solution is so perfect.

> Back to OP's article where they look at some isolated properties to then declare a protocol secure.

Yes, that's a problem. Let's try to promote more informative resources. We joinjabber.org people appreciate all feedback and criticism to turn into docs. You're always welcome by xmpp:privacy@joinjabber.org?join chatroom if you have more info and/or would like to run more experiments in regards to privacy and security in the XMPP ecosystem.

Re: XMPP: The secure communication protocol that respects privacy

#83

Post by jancsika »

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

> Signal enforces E2EE, you can't disable it.

Exactly!

It seems like there is a combination of tenuous assertions being made about XMPP security here, followed by naive questions from people who apparently don't understand the basic feature set of something like Signal. Any clue why this is happening?

Re: XMPP: The secure communication protocol that respects privacy

#84

Post by southerntofu »

gkdr wrote: post #80
southerntofu wrote: post #76

Earlier quoted context omitted.

Pidgin is not listed as supporting OMEMO [0] and is not recommended for newcomers on joinjabber.org [1]. There may be reasons you want to use Pidgin and i don't want to block you: also pidgin is not exactly abandoned so there's hope it will continue to improve. When a web browser fails to display a certain page, would you recommend the site operator to block it? Maybe we could allowlist specific clients and send a wa…

the omemo support in pidgin is just through a plugin, as with many recent XEPs. i think people tend to forget that pidgin's focus is being a multi-protocol messenger. it ships with XMPP support, but that mostly includes the base. i wrote that omemo plugin and tbh I am pretty burned out. so many moving parts, it's hell to debug and i'm not even sure where to go next with it. (plus people keep talking badly about pidgi…

> i think people tend to forget that pidgin's focus is being a multi-protocol messenger.

That's what's great about it and part of the reasons i think blocking Pidgin would be very wrong.

> i wrote that omemo plugin and tbh I am pretty burned out.

Thanks for that work! Maybe you could start by writing about your burnout on the README to encourage other people to contribute/maintain, or at least be less demanding of you?

> it's hell to debug and i'm not even sure where to go next with it.

Do you think this is specific to your plugin? To OMEMO? Or to pidgin plugins in general? Personally, i find it very challenging to write correct code in C, and i can only imagine the pains pidgin developers have to come through to make so many networks/protocols inteoperate. If you have some reading about your experiences, what lessons we can learn, and maybe some project (whether internal to pidgin or not) to implement them, i'd be interested to read.

> sorry if someone feels let down.

I don't think anyone feels really let down. Some people are not aware of just how experimental certain things are and so they get disappointed but life goes on. You however should take care of your mental health and not let maintenance burden and heartless cyber-ranters like me affect your mood and taste for computing <3

Re: XMPP: The secure communication protocol that respects privacy

#86

Post by qwertox »

It angers me so much when my browser tries to connect to a port other than 80 or 443 and the firewall pops up [0] and even more if I decline the request and it keeps popping up because the page doesn't understand that I don't want to accept this.

Other than that, I absolutely love XMPP. It's the platform my servers and applications use to inform me of events, and with Conversations [1] there's a really nice Android app as a client.

[0] https://matrix.cactus.chat:8448/_matrix/client/r0/register?k...

[1] https://conversations.im/

Re: XMPP: The secure communication protocol that respects privacy

#88

Post by MattJ100 »

infosechandbook wrote: post #63
zaik wrote: post #56

Earlier quoted context omitted.

In Conversations unauthenticated messages are displayed with a red background, whereas OMEMO authenticated messages are displayed in green. They do not look the same.

Nobody claimed that they look the same. As mentioned in the linked article, the behavior upon receiving an injected message is client specific. In any way, the injected message is somehow presented to the (non-technical) user who might then be targeted. We all know the same problem exists in the e-mail world.

Signal operators can also inject messages to people. So this is a strange comparison.

What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. Which is the entire point of E2EE.

Re: XMPP: The secure communication protocol that respects privacy

#89

Post by judge2020 »

edhelas wrote: post #73
m4lvin wrote: post #27

Earlier quoted context omitted.

I wanted to try it out, but this is annoying: - registration happens on https://api.movim.eu/register and firefox provides me a way to generate a password and save it linked to that domain. - now I want to log in at https://mov.im/?login but firefox has no idea that it should use my api.movim.eu account for that.

Yes this is perfectly normal. The XMPP account (so movim.eu) is decorelated from the mov.im pod we deployed as a public instance to show up the project. You can connect on Movim (and mov.im, the official pod/instance) using any XMPP account. movim.eu is just one amongs all the others. You have to differenciate Movim as a project that particular instance deployed as mov.im and the Movim XMPP server that we deployed fr…

I think this is the same problem matrix has: you end up entering your login details on foreign domains. There's really nothing stopping them from capturing that login via malicious javascript and using it for some malicious mitm, or just saving it to try on other services (you can't expect everyone to use a randomly-generated password). I don't see why you couldn't just enter 'server.com' (your xmpp server) and have an OIDC flow performed (the same complaint goes for matrix).
Post reply on HN