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…
XMPP: The secure communication protocol that respects privacy
91–100 of 160 posts
Re: XMPP: The secure communication protocol that respects privacy
#92Earlier quoted context omitted.
Well, matrix does a lot of things different. A rewrite seems pretty unavoidable with hat many and significant changes
What's so different about it? Historically XMPP was more geared towards message-passing without server-side archival, but that ship has long since sailed to support multi-client. As it is, i don't see any significant change except for the consensus algorithm for decentralized rooms which could very well be an extension to the XMPP s2s protocol.
Re: XMPP: The secure communication protocol that respects privacy
#93Earlier quoted context omitted.
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.
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: One system enforces E2EE; for the other system E2EE is optional, depends on the client, and while spoofing could be detected thanks to E2EE, all clients we checked didn't detect it (Gajim, Conversations, Psi+, Profanity).
Re: XMPP: The secure communication protocol that respects privacy
#94Earlier quoted context omitted.
> 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…
Unfortunately, this seems to be the starting point of most discussions on XMPP. Somebody claims that XMPP solves all problems, and is secure and private. Or they present a highly-customized, non-default XMPP setup and compare this with an out-of-the-box competitor to show the superiority of their setup. We rarely see posts like your FAQ on the internet.
> ... or the worst
In case you refer to our article, we don't claim this. We recommend to self-host your XMPP server (if you can), or to migrate to alternatives instead of blindly trusting unknown entities on the internet. We are also not the police on the internet. People can choose what they want, including WhatsApp, Telegram, XMPP-based messengers, Signal, or whatever messenger they use.
> Let's try to promote more informative resources.
We will link to your FAQ. Thanks for providing more balanced content.
Re: XMPP: The secure communication protocol that respects privacy
#95Earlier quoted context omitted.
> Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?
At the time of reception, the Signal server knew that there was a message from a certain IP to a certain recipient. If the message was put in the queue, the originating IP was forgotten. Once the message is delivered, the recipient is forgotten. EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal. As neighbor comments have said it still knows at that moment that a message from you is sen…
For a centralized service like Signal, your IP doesn't matter, they own your account, literally. You can randomize it as much as you like, and your peers may too, in the end it will not hide from them who sent a message to whom and when.
Re: XMPP: The secure communication protocol that respects privacy
#96Earlier 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.
My problem is that I'm using several clients (mostly profanity on several machines, occasionally dino) for the same account and it seems that my contacts keep forgetting some of my OMEMO keys, so I often receive messages that some of my clients can't decrypt and I have to start multiple machines just to find one that can decrypt the message.
So far I haven't figured out how to debug this.
Re: XMPP: The secure communication protocol that respects privacy
#97The 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 fucking sucks big time. And it is precisely this flexibility that makes it suck. It's not just flexible, it's a mess. And mobile support in 2021 is atrocious.
There's a reason why Telegram's very shitty protocol is vastly more popular for average Joes than XMPP ever was.
XMPP was designed by engineers, for engineers. Which is good for this very specific set of engineering problems and essentially useless for everyone else.
Want secure communication? Use Signal, Threema, hell even Telegram is more secure in its default canonical protocol implementations than XMPP. And stop beating the dead horse XMPP is.
Re: XMPP: The secure communication protocol that respects privacy
#98Encryption 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.
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.
that's not true for most clients, though (AFAICT, only riot works with itself).
I might even say that the situation is better/more sustainable in XMPP where more diverse implementations of the encryption protocol are available, with all mainstream clients supporting it: https://omemo.top/
Re: XMPP: The secure communication protocol that respects privacy
#99Earlier 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.
Re: XMPP: The secure communication protocol that respects privacy
#100On XMPP, encryption is optional and not even the default. I'm very unlikely to recommend it to anyone over alternatives that default to end to end encryption, or even require it.
Which are they? Alternatives that require you to reveal your identity (via a phone number), or to reveal your whole social graph/usage patterns (by being organized around a single actor in the middle knowing about everything and everyone in the network)?
Federated and P2P networks are the only true alternatives for the privacy/security conscious.
> On XMPP, encryption is optional and not even the default.
OMEMO encryption is widespread/practically universal these days. You are pretty much guaranteed to be able to establish an E2EE session would it not be the default for any reason.