E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2
matrix.org
matrix.org
While... frustrating to see that these vulnerabilities exist, I'm happy to see that at least the bulk of them require a malicious homeserver.
And Matrix makes it easy(ish... if you're a sysadmin type...) to run your own homeserver.
I've generally assumed in the past couple years of running Matrix that if someone else controlled my homeserver, they could probably do something malicious, which is why I run my own, on hardware I control. Perfect? No, but it's a sure bit better than running on some major tech company's chat infrastructure.
The main problem is I don't know of anything better, short of just giving up and going back to IRC - which, even with znc, isn't nearly as nice as Matrix/Element/etc, though it's far lighter to run at all ends. And IRC is mostly just plaintext (yes, there are some plugins that help, no, they don't really work reliably in my experience with them).
I'm open to being convinced otherwise, but even with this bit of a charlie foxtrot going on, I still think Matrix is probably the least-awful of modern chat options, if you can run your own homeserver.
And then there is Conduit which is written in Rust
However, I've got my own box colo'd, so I can give plenty of resources to the VM it runs in, and it seems to hold up just fine in operation.
Realistically, the bulk of my traffic is to other users on the same homeserver, so I'm less likely to notice sync/federation issues. A few people do talk across different servers, though, and would bug me if something was broken. It seems to be fine, just very CPU and RAM heavy for what a chat server ought to be using in my view of things.
I won't claim it's perfect, but it does provide for a robust and modern-ish chat service that's not reliant on the good will and data monetization of major tech companies.
The following give some details:
* https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca...
* https://twitter.com/matrixdotorg/status/1434912387933560837
What's more the Synapse team recently announced support for Rust meaning that various performance critical sub-components can be ported over from Python.
* https://matrix.org/blog/2022/09/09/this-week-in-matrix-2022-...
As mentioned elsewhere Dendrite (Go) and Conduit (Rust) are both entirely useable albeit beta implementations.
I like Matrix a lot, but the way I use IRC: for public rooms. For private discussions, I use Signal Messenger, which seems to get e2ee right, and does clever stuff to reduce their access to metadata (pretty sure matrix homeservers have to know in which rooms I am to fetch my messages, right?)
As far as Signal goes, my main concern there is just how centralized it is. I would assume "anyone with the interest and ability" is monitoring messages going to and from Signal, which would be at least somewhat easier than monitoring stuff to all the random homeservers out there.
... fundamentally, I'm not sure the internet is trustworthy at all, anymore. :(
That's the whole point of end-to-end encryption: you don't have to trust the server if e2ee is done right. Matrix is decentralized, but as this disclosure shows, they have issues with e2ee. Signal is centralized, but I have never, ever heard of a security issue with the Signal protocol.
So yeah... you may have concerns about Signal being centralized (e.g. they have the power to shut it down, and I guess they could ban users), but end-to-end encryption is not one. Actually Signal probably has one of the best e2ee out there.
The two critical bugs in question here were similarly implementation bugs in matrix-js-sdk and its derivatives.
Separately, there’s a question over the fact Matrix by design controls group membership on the server… and warns users if malicious devices get added, rather than explicitly forbidding them. We’re fixing that anyway, but it’s questionable if this counts as “issues with e2ee” - it’s similar to deriding Signal for pushing all the users in your addressbook when you join the app(!)
I was talking about the Signal protocol.
> it’s questionable if this counts as “issues with e2ee”
Fair point. It's not a problem in the encryption protocol, but it is a design problem on the group membership control.
Now I think it's not completely fair to compare that to the Signal private contact discovery, which relies on SGX enclaves. First, because it's private (if you trust the SGX enclave technology), and second because even if it was not, I believe it is a pretty different level of "design problem": "if the secure enclave does not work, then the server can access a hash of your addressbook" vs "if the whole system works as expected, AND you don't constantly keep an eye on the group members, it could be that a malicious actor reads the content of your messages".
Or am I misunderstanding something?
However. Does anyone else feel uneasy about Matrix end-to-end encryption and how some people justify its provenance by asserting it is the same encryption as Signal despite the homebrew implementation by Matrix having obvious differences to attempt to accommodate multi-device support among other features?
Signal's implementation (assuming it's what they say it is) is equally "homebrew"; it was derived from OTR but it's not the same protocol, and things like the server-assisted initial key exchange are both bolted-on and often omitted from security analysis in a way that I find very dubious.
(Frankly the only crypto protocols mature enough that I really trust them are PGP, TLS, and maybe SSH, but I don't think any of them are suitable for a use case where you want to avoid non-repudiable signatures)
You mean the Extended Triple Diffie-Hellman? What do you mean by "bolted-on"? Would you consider it "bolted-on" too, if it was just a normal Diffie-Hellman (hence not asynchronous)?