E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2(matrix.org)
matrix.org
E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk2
https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients/
19 comments
If you run your own homeserver and talk to people on homeservers you trust, that's fine. Now chances are that you talk to people who are not on your server, right?
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?)
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?)
My server is federated and seems to work that way, but... mostly, I talk to people on the server, or via my bridges.
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. :(
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. :(
> As far as Signal goes, my main concern there is just how centralized it is.
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.
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.
Signal has security bugs line the best of them. The most famous is probably https://thehackerblog.com/i-too-like-to-live-dangerously-acc... - which gave full RCE, letting the attacker steal all your messages or worse.
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(!)
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(!)
> Signal has security bugs line the best of them.
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?
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?
Is Synapse not infamous for its memory consumption and losing sync with other homeserver(s)?
Synapse has come a long way in the past few years both in terms of reliability and resource usage.
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.
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.
It's far heavier than I'd prefer, yes.
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.
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.
Well dendrite is beta software. Ive been running it for almost two years now and its close to synapse in functionality now while being super lightweight compared to it.
And then there is Conduit which is written in Rust
And then there is Conduit which is written in Rust
Write-up of the vulnerabilities and attacks by research team who reported them: https://nebuchadnezzar-megolm.github.io/
One of my biggest pain points in setting up an unfederated homeserver for my friend group was trying to figure out how to not have so much access as the server admin. I am nowhere near an expert at cybersecurity or cryptography or sysadmin things, but I had a strong sense of "I shouldn't be allowed to do this" - for example, when users had difficulty verifying their sessions, I was able to simply click a link in Element to "manually verify" the user on behalf of the entire encrypted group. This was several years ago and the verification flow seems to have improved since then, but that gave me some misgivings.
Certainly glad these vulnerabilities were disclosed and patched without exploitation by malicious entities.
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?
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?
> 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)
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)
> 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.
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)?
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)?
Quite bad vulnerabilities in some cases, but the fact none of these bugs were on the protocol level is a good look for the ecosystem as a whole.
Several of these bugs were indeed on the protocol level: https://nebuchadnezzar-megolm.github.io/
Some more comments over here: https://news.ycombinator.com/item?id=33009721
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.