Live data from Hacker News

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

51–60 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#51

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 already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983

I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files.

It's much more important to me that I know where my data is - or rather, know where it isn't. I'd rather have that than be forced to entrust my metadata to a third party such as WhatsApp/Facebook, Telegram or Signal.

Disclaimer: I'm an XMPP developer (as I know you know, but others may not).

Re: XMPP: The secure communication protocol that respects privacy

#52

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…

XMPP leaks less metadata than alternative like Matrix, but it still very vulnerable to traffic correlation attacks from an external observer, server compromise and malicious server admin. Far from ideal.

Briar mitigates[1] these risks by using p2p messaging over Onion Services.

[1] mitigates: it's well known that even Tor cannot protect from correlation attack from a global observer but mounting such attack requires billions (see PRISM). Correlating traffic from/to an XMPP server is trivially easy for any person that has access to logs from a network device or can run a tcpdump on an hypervisor.

Re: XMPP: The secure communication protocol that respects privacy

#53

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…

You mention IP address, location based on IP addresses, timestamps, bytes transmitted and number of packets as metadata which is disclosed to the server admin. What alternative messenger do you suggest which does not disclose this metadata to the server operator?

Re: XMPP: The secure communication protocol that respects privacy

#54

Earlier quoted context omitted.

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

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

Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"?

And how about looking at more than just an isolated property of a competitor?

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

XMPP servers are a gold mine when it comes to metadata.

Re: XMPP: The secure communication protocol that respects privacy

#55

Earlier quoted context omitted.

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

But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that?

The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than Signal.

XMPP encourages people to build clique servers, which fail a key security requirement "Don't Stand Out". The six other users of "Bob's 100% Preparedness Militia and True Patriots Server" may be quite sure Bob is trustworthy and won't rat on them, and maybe one of them only uses it to post funny GIFs of cats, but the loose metadata association between this group and a plot to kidnap a State Senator means all seven of them are targets anyway.

But if you try not to stand out by using a popular server, that server's operators have far more insight into you than Signal's server operators do. Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. I know, because I decrypted the message, but Signal does not. That's a bunch of heavy cryptographic lifting, but from their point of view it was worth it to improve privacy.

Re: XMPP: The secure communication protocol that respects privacy

#56
post #45

Earlier quoted context omitted.

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

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

Re: XMPP: The secure communication protocol that respects privacy

#57
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?

I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks.

It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.

Re: XMPP: The secure communication protocol that respects privacy

#58
post #16

Earlier quoted context omitted.

How resistant to MITM is it though? Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time. Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of…

Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that…

That sounds significantly more complex and worse than how Matrix just works out of the box.

Re: XMPP: The secure communication protocol that respects privacy

#59

Earlier quoted context omitted.

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…

XMPP leaks less metadata than alternative like Matrix, but it still very vulnerable to traffic correlation attacks from an external observer, server compromise and malicious server admin. Far from ideal. Briar mitigates[1] these risks by using p2p messaging over Onion Services. [1] mitigates: it's well known that even Tor cannot protect from correlation attack from a global observer but mounting such attack requires…

Traffic correlation attacks are very difficult to mitigate. Even Tor is not immune to this (see research such as [1], and the Tor project's own statements that the design is not resistant to analysis by a global network observer). Also Briar may be unsuitable for some use cases where you want to remain anonymous to people you communicate with[2].

Some research has been done into communication networks that are resistant to traffic analysis, such as Vuvuzela[3]. Unfortunately most such solutions requires permanent connectivity and bandwidth utilization, which makes them impractical for battery-powered mobile devices.

I'm firmly of the belief that no communication tool is suitable for all use-cases, but that we need to build open interoperable ecosystems that fulfil a range of needs, and help educate people about them.

[1]: https://nusenu.medium.com/the-growing-problem-of-malicious-r...

[2]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b...

[3]: https://vuvuzela.io/

Re: XMPP: The secure communication protocol that respects privacy

#60

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 already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983 I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files. It's much more important to me that I know where my da…

> I already responded to your "admin in the middle" article here

And we already responded here: https://news.ycombinator.com/item?id=29106376, and here: https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/, and somewhere on Reddit.

> I run my own XMPP server (Snikket) for my family

Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Can we agree that most non-technical XMPP users use a public XMPP server on the internet, where they might not know the individual or organization running the server? Where it remains unclear whether the XMPP server is set up and operated in a "secure" and "private" way? Where some XMPP server admins even fail to provide a privacy policy or try to hide their identity? Is this unique to XMPP? No, we never said this. Is this then a reason to ignore these issues? Also no. We should openly discuss pros and cons instead of highlighting isolated properties of a protocol that might be better in some situations than the same properties of a competitor.

Post reply on HN