Live data from Hacker News

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

11–20 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#11
post #4

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.

Re: XMPP: The secure communication protocol that respects privacy

#12
post #9
post #5

Earlier quoted context omitted.

Matrix supports encryption out-of-the-box without any strange key exchange problems. Most of the time the way key exchange is done in XMPP is very insecure.

> Most of the time the way key exchange is done in XMPP is very insecure. We have OMEMO now, key exchange is paranoia-level secure.

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 the old times in [matrix].

This opens room for MITM attacks

Re: XMPP: The secure communication protocol that respects privacy

#13
post #3

Earlier quoted context omitted.

I've seen movim around but I have never actually tried it. This post gave me the push. So thank you for that. I do have a question though: On https://mov.im/?login it says: "Login using any XMPP account or create a new one" But it only shows me a login form where I can enter my xmpp address and a password. This signals to me that I can log into my existing non-movim-xmpp account, but I have to enter my password on th…

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 like this does not seem a great idea.

Re: XMPP: The secure communication protocol that respects privacy

#14
post #11
post #4

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.

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

Re: XMPP: The secure communication protocol that respects privacy

#15
post #14
post #11

Earlier quoted context omitted.

XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.

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?

Re: XMPP: The secure communication protocol that respects privacy

#16
post #9

Earlier quoted context omitted.

> Most of the time the way key exchange is done in XMPP is very insecure. We have OMEMO now, key exchange is paranoia-level secure.

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 it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere?

Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key.

In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident.

> This opens room for MITM attacks

Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.

Re: XMPP: The secure communication protocol that respects privacy

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

The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.

Re: XMPP: The secure communication protocol that respects privacy

#19
post #17

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?

The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.

That's an issue with any cross-protocol accounts, and will only be solved the day something like MLS comes up.

Re: XMPP: The secure communication protocol that respects privacy

#20
post #4

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

Depending on when you last tried xmpp you might have experienced the OTR hell, which was never really codified 100% and spawned subtle incompatibilities between clients leading to weird and nondescript errors that never got addressed. Nowadays the popular clients support omemo (https://conversations.im/omemo/), which makes encryption just work™ out of the box and without hassle. The only exception to this is xabber, who are apparently afraid of law enforcement destroying their lifes should they implement proper encryption and also feel no need to support it anyways: https://github.com/redsolution/xabber-android/issues/540
Post reply on HN