Disclosing E2EE vulnerability in multiple Matrix clients
matrix.org
matrix.org
And even if you own the homeserver, you still want E2EE since you don't want the data to rest in plaintext server-side.
However, there is work currently being done to make it feasible for every node to also be its own homeserver, via P2P Matrix (https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix).
It isn't helped by the fact that the backup process is a bit obscure and doesn't work cross operating systems. For the select few that cares, verifying keys is effective against attackers who aren't Signal themselves, Google or in control of the Play Store. Just make sure to keep an eye out for that key changed warning, it's easy to miss.
If you don't verify the keys, e2ee is basically meaningless against targeted surveillance. As long as some fraction of people verify keys, it is still effective against mass indiscriminate surveillance.
Generally, I'd argue that E2EE provides defense in depth against "unknown unknowns" if server infrastructure is compromised by any means. Although I do acknowledge it adds one more level of complexity, and often another 3rd party dependency (presuming you're not going to roll your own crypto), so it's not a strict positive.
Only if everyone's running their own personal homeserver, which seems pretty unlikely for regular people. You could've said the same thing about email (it's not meaningfully different unless your personal email server is compromised), but in reality the NSA ran mass surveillance on gmail and picked up a lot of data that way.
But also: why the heck wouldn't you want to encrypt it? The existence of leaks doesn't make basic prevention useless.
Of course, I think self-hosting and decentralizing the servers is very important and good work too!
Matrix is way ahead of you. There's ongoing work to build P2P clients [0]. That is, each phone/device can be its own home server. The latest update was in May [1].
[0]: https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
[1]: https://matrix.org/blog/2021/05/06/introducing-the-pinecone-...
Matrix P2P removes the homeservers, but clients are still talking to each other through some medium that can impersonate them.
There's really no magic solution to solve this, you need either a trusted third-party (such as Certificate Authorities, who are expensive) or a Web of Trust (impractical for users).
Or if you prefer threats: "If I die from covid before matrix p2p is a thing, my ghost will haunt you for evar!".
Personally, I think it's really nice that in P2P Matrix precisely the same client-server API is used as for normal Matrix, so all the work that goes into the Matrix client and E2EE etc is preserved without any changes at all. Instead, it just talks to a server running on localhost, which then replicates traffic around over the P2P overlay (in future using store-and-forward servers if the target server is offline). It's really not a bunch of hacks, thanks to Matrix being architected to make the replication transport & protocol pluggable from the outset.
Like really, my Palm TX could do that via infraport!
So any effort to break this stalemate makes me very happy. :)
I have come to the conclusion that the inability to communicate is not a fail but intended.
It seems like security and business interests are standing in the way, not primarily technical hurdles.
Mesh networking and service discovery are issues where technical solutions exist. But their application is slowed or blocked by network operators and phone/OS manufacturers to enforce a central authority and paying subscribers.
Privacy concerns are often used to explain these decisions, but I see those as mere excuses. Mesh node identifiers could just be randomly regenerated periodically or handled anonymously. Also firewall rules could easily ensure only authorized services can communicate.
It was interesting to observe how quickly similar P2P features were enabled in the fight against Covid-19 (contact tracing via BLE advertisement packets).
At the same time it is harder than ever to use, for example, Android's WiFi or Bluetooth in an App-controlled manner. Only the central authority, not the owner of the device nor independent App developers are apparently supposed to actually use the devices capabilities.
Quite frustrating.
I have been thinking about building a generic case/USB gadget to enable free communication, but such a solution would have many drawbacks versus using the internal radios.
The involved parties want to sell you cloud services(hello Google!), to have you use up mobile data & calls/SMS (hello operators! ) and ideally to throw the phone away after a year or two (hello manufacturers).
And all they need to do is build a device OS combo that needlessly peddles data via cloud somewhere on the internet, has not data card slot and can't talk directly to similar device on the table next to it...
They are already moving beyond that - towards P2P Matrix, with a network mixing traditional servers and individual nodes that collapse client and server: https://matrix.org/blog/2021/05/06/introducing-the-pinecone-...
Maybe this could be helped if Matrix clients supported OpenPGP encryption which allows for key signing/web of trust? Some XMPP clients already have OpenPGP support, it would be nice to one day be able to send encrypted messages to Matrix users.
1. Those who care about encryption are able to verify their keys.
2. The service can't implement mass-surveillance in secret if there are at least two random users who verify their keys.
The problem is, it isn't easy at all. Running homeserver requires gigabytes of RAM and significant CPU performance to work at usable speeds. It just isn't feasible to run it on some dirt cheap VPS, you need beefy machine.
disclaimer: I tested it some time ago with Synapse. Now I see there is also new homeserver software, Dendrite. It is possible that it is order of magnitude less resource hungry, though I wouldn't count on that.
It's not the slimmest beast, in part because Synapse needs to scale up to country-scale deployments, but its ability to scale down has significantly improved over the past year.
That said, Dendrite and Conduit (https://gitlab.com/famedly/conduit/) are exciting projects which will optimize for different operational contexts.
I'm also not even using Synapse workers at all, just a monolithic instance. Splitting the setup into workers would buy me an additional speedup if things got overly slow.
Not the Matrix team's fault, but still a bit worrying. Maybe they could implement their own F-Droid repo to skip the F-Droid build server?
Because F-Droid runs their own builds and requires published source code, there is no mechanism for pre-building and staging security releases for issues which are not yet publicly disclosed.
That said, the packager was extremely helpful and prepared the metadata updates in advance to ensure that both applications could enter the build queue as quickly as possible upon release:
- Element 1.2.2: https://gitlab.com/fdroid/fdroiddata/-/commit/76c8f5b87aa8df...
- SchildiChat 1.2.2.sc43: https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0...
That seems… completely reasonable for distributors of open-source projects. Mandatory, even, for compliance many open-source licenses. Are you saying there are other open source repositories (e.g. Linux distros) which would not require published source code before distributing binaries?
(After verifying that the public source is identical to the privately shared copy, of course.)
That way distros can do a local build to verify the patch works and fixes the issue & they then apply the patch in their public infra right after the embargo runs out.
You can see here the history https://gitlab.com/fdroid/fdroiddata/-/commits/master/metada...
You can donate to support them here https://opencollective.com/f-droid or here https://liberapay.com/F-Droid-Data
I was under the impression that reproducible builds guard against the "fdroid build servers got compromised" attack vector, (or "developer got compromised", as compared to dev-signed releases) and nothing else.
Currently, most things are signed by F-Droid, so distributed building is harder. But later less trusted servers could build the apps and check, leading to a consensus system.
> We will also accelerate our work on matrix-rust-sdk as a portable reference implementation of the Matrix protocol, avoiding the implicit requirement that each independent library must necessarily reimplement this logic on its own
I like the idea of providing a core Rust/C++ library that can be called in any other runtime via FFI, compiling to WebAssembly, etc. I've used the same technique to ensure consistency in usage of a custom time-series compression format across an organization. Overall this technique seems in-line with the "DRY" principle, and the tradeoffs have been favorable in my experience. I think it will be a good step forward for the Matrix ecosystem.
Separately, there's also the overall matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk for clients to use as a "full fat" Matrix client SDK - as used by Fractal Next (https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next) etc. We might end up using this in Element too in future (especially in Element iOS, where a Swift UI + matrix-rust-sdk backend could be quite a cute next generation architecture).
So while the first generation reference Matrix SDKs (matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk) were completely independent implementations, each with their own bugs and increased audit surface, we're hoping that matrix-rust-sdk will simplify this a lot in future.
I throw messaging apps in the same category as, for example, web browsers. It's really tough to try an alternate implementation if you're worried that they might have broken a complicated security feature. So having more shared crates mitigates some of that risk.
Now, you're right that key-sharing is a useful way to fudge around that failure mode.
But an even better way to fix it would be to find a way to stop the OTK pool exhausting - and that's precisely what MSC2732 is: https://github.com/uhoreg/matrix-doc/blob/fallback_keys/prop.... This provides a last-ditch key which can be used to set up 1:1 sessions even if you run out of OTKs, which is marginally inferior to using a different OTK every time, but in practice really isn't a disaster (see the MSC for details).
However, fallback keys are relatively new and aren't implemented on all clients yet (matrix-js-sdk has them, but matrix-ios-sdk is implementing this coincidentally this week)... and so until they land, we still need keyshare requests to paper over this limitation.
But in future, hopefully it will be almost unheard-of to need a keyshare request, and we can change them to be an entirely manual or out-of-hand mechanism of some kind, and avoid classes of bugs like the vuln in question here in future.
Is 100 a safe default for devices with limited memory, or are there other more salient constraints that I'm ignorant of?
100 seems like a reasonable middle-ground between "that's a lot of storage to address a rare edge case" (e.g. say this was 3.2TB) and "most people will never need 10".
No? Assume the lost/stolen/forgotten device has outdated (or no) protection around its keys - and it should be rotated out as soon as possible?
I'd rather not have to worry about if my old phone is in my drawer at home, or in an mi6 office (or more likely, with an estranged spouse or a journalist)?
otherwise, do you really want to rely on the OTK pool exhausting as a very handwavey way to provide post-compromise security? A much better solution would be to have a firmer metric for your server to explicitly kick out your devices after N days of inactivity. Relying on some weird bug like OTK pool exhaustion for security purposes is horrible.
I've filed an issue at https://github.com/matrix-org/synapse/issues/10813 for inactivity timer logouts.
However, my point still stands that fallback keys are a good idea - you should kick the device out deliberately (manually or with a timer) rather than rely on a protocol quirk meaning that E2EE randomly breaks after some period of inactivity(!)
The Element client (desktop/web/android) is electron-based https://element.io/get-started Synapse is the server to start with https://github.com/matrix-org/synapse/
From there, what's the first place to find people to chat? I don't have a good answer there, but the 'spaces' functionality is a nice way to group communities.
I started trying it, with the Element.io apps and convinced a techy friend to try it. Since then, he set up his own server and we have a group of friends that we mainly communicate through matrix. Also, I try to use it with my parents. They want to use it, but end up writing to me through WhatsApp out of muscle memory.
After some time I started looking at public rooms that I'd be interested into, available in matrix.org or matrix.feneas.org.
The easiest way to start, though, is to create a free account in the matrix.org public server using the webapp[0].
Disclaimer: I work @ Beeper
For example, the NixOS community has a curated Matrix Space linked from https://nixos.org/community/index.html with lots of rooms to explore. GNOME, KDE, and Mozilla also have a significant presence on Matrix.
I hear this on occasion (though more rarer nowadays than in the past)...But curious, is there something specific that you're finding in matrix that is not yet settled? By all means, the beauty of open source stuff is that you get to choose whether you (and your circle of contacts) uses zulip, mattermost, etc...So, i encourage you to use whatever open source offering gives you (and your circle of contacts) what is needed/desired. But with me being such a fanboy of matrix, i always get curious. Would you care to share specifics?
I'm a bit curious why you'd ever need to request those keys from somebody else, in addition to your own devices (or your homeserver, where they'd be stored encrypted by a key known by your own devices).
It's acceptable to gossip keys between your own devices (assuming you authenticate them correctly!) given... they're all your own devices.
It's also acceptable to request the sender to re-send the keys to you, given the sender knows for sure whether you were allowed to receive the key (given it made that choice in the first place).
It's not acceptable to request keys from other devices in the room, as they won't necessarily know whether you were actually allowed to receive the message key you're requesting - only the sender knows for sure whether it should have been sent to you; it was their key after all. Plus it would risk make vulnerabilities like the one in question here even worse, given anyone could try to exfiltrate messages from anyone else, rather than "just" the sender (as was the case here).
Based on what I understand about this feature, I've had to rely on key sharing quite often (even requiring manually requesting keys a bunch of times) for E2EE to work reliably. I worry that my experience will be severely degraded if key sharing ends up being removed from the protocol.
Having the sending party re-encrypt messages for a new device require the other party to be online. I can see that requirement not being met in several ways, e.g. if the other party dies or uninstalls the application, or when the other end is arrested (I can imagine journalists losing access to activists' messages because of this).
This is because it's papering over edge cases in E2EE.
> Having the sending party re-encrypt messages for a new device require the other party to be online
We never make senders re-encrypt messages like this, and we never would.
Firstly, key-sharing from the sender does require the other party to be online already.
Otherwise, if you have the keys in an existing device, you could get them onto your new device by backing them up on the server - or using "dehydrated" devices; where the 'new' device you log into is actually one which is stored encrypted on the server, and "re-hydrated" into a new device when you login... and so already has your keys. These have security trade-offs obviously (what if your online backup gets pwned? what if your dehydrated device gets pwned?) but it's not obviously worse than exfiltrating the missing keys from the sender.
Doesn't the fact there's some kind of mechanism or expectation of sending encryption keys willy nilly imply a flaw with the protocol perhaps?
It's not though. The fix is to cryptographically verify requesting clients before sending.
You can set it to "only other clients and people I have personally verified" but that is quite cumbersome for big channels that just don't want clear text.