Live data from Hacker News

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

111–120 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#111

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.

> Nobody show them Signal or their head might explode.

Most popular XMPP encryption is literally signalprotocol, so I'm pretty sure the community is aware :)

Re: XMPP: The secure communication protocol that respects privacy

#112
post #73
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…

Login should happen on a single domain (same one that was used for sign up). Just redirect from mov.im to movim.eu and back, same as Oauth.

Re: XMPP: The secure communication protocol that respects privacy

#113

XMPP is dead and I'm very happy about that. The only people who still use XMPP in a significant capacity are the likes of Nintendo (for the Switch push notifications system) and it is pretty out of reach for any average citizen. XMPP as a protocol for engineering and science is fantastic. As a set of standards it's well designed. Performant, flexible, and powerful. As a general, average Joe software however it fuckin…

> And mobile support in 2021 is atrocious.

I'm curious to hear of any specific mobile issues you are aware of. Most of our customers use XMPP exclusively from mobile and I have not heard complaints so far, but it's only been 5 years so far...

Re: XMPP: The secure communication protocol that respects privacy

#114

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.

Hard to believe someone compares proprietary centralised silo service like Signal to an open federated protocol.

Re: XMPP: The secure communication protocol that respects privacy

#115
I'm not going to say that you can't build a secure messaging system with XMPP, but you should be skeptical of any analysis that suggests that XMPP is secure because it uses TLS, and "engineers are working on E2EE to add even more security". The security you get from TLS in these systems is not meaningful, and by the "it uses TLS" definition, virtually every messaging system is "secure".

Re: XMPP: The secure communication protocol that respects privacy

#116
post #14

Earlier quoted context omitted.

It still would be nice if Matrix was built upon the existing Internet Standard for instant messaging.

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?

Without too much difficulty. Just needed some XEPs. But matrix devs had a severe case of NIH syndrome.

Re: XMPP: The secure communication protocol that respects privacy

#117

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

You think you're making an argument against Signal, but you're in fact making the argument for it. The reason Signal deals in your phone number is precisely to keep them from managing databases of metadata about who's talking to who; the phone numbers keeps the social graph on the clientside.

Go look at RFC6121 Section 2 for one example of this. The point of Signal's design is that the server can't facilitate this kind of transaction, because it's unsafe for the server to keep that data in plaintext.

Re: XMPP: The secure communication protocol that respects privacy

#118

I'm not going to say that you can't build a secure messaging system with XMPP, but you should be skeptical of any analysis that suggests that XMPP is secure because it uses TLS, and "engineers are working on E2EE to add even more security". The security you get from TLS in these systems is not meaningful, and by the "it uses TLS" definition, virtually every messaging system is "secure".

> The security you get from TLS in these systems is not meaningful

I don't like that phrasing, because it suggests that having TLS is equally good than not having TLS.

Otherwise, you are right.

Re: XMPP: The secure communication protocol that respects privacy

#119
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 admins too can ship you an app version that would show injected messages like coming from legitimate sender. [1]

However, while you can be your own xmpp server admin, you can't be Signal admin.

[1]: And for god's sake pls don't even start on reproducible builds, nobody really verifies every app updates.

Re: XMPP: The secure communication protocol that respects privacy

#120

Earlier quoted context omitted.

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.

> Signal operators can also inject messages to people. Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spoofed messages? Would be nice to see for the security community. > What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. What also holds true: O…

If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.
Post reply on HN