E2EE vulnerability in multiple Matrix clients

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • GitHub repo fdroiddata

    Element did coordinate with the F-Droid packagers on behalf of both Element Android and SchildiChat.

    Because F-Droid runs their own builds and requires published source code, there is no current 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...

  • GitHub repo matrix-rust-sdk

    Matrix Client-Server SDK for Rust

    The current way we're approaching this is to split the reference E2EE implementation into its own rust crate (https://github.com/matrix-org/matrix-rust-sdk/tree/master/ma...) which can be used with any SDK (e.g. we're almost finished embedding it into the Kotlin matrix-android-sdk2 client)

    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.

  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

  • GitHub repo Synapse

    Synapse: Matrix homeserver written in Python 3/Twisted.

    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 'rooms' functionality is a nice way to group communities.

  • GitHub repo matrix-doc

    Matrix Documentation (including The Spec) (by uhoreg)

    This is a great example of why key-sharing exists today... and why it shouldn't. In theory, you should be able to pick up and old client and decrypt new messages and history on it absolutely fine. However, in practice, Matrix's E2EE publishes 100 one-time keys (OTKs) on your server to let other devices establish secure 1:1 channels with you if you're offline - and if you go offline and that pool of OTKs exhausts, then new sessions won't get set up and you won't receive keys for new messages... giving the misbehaviour you're seeing.

    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.

  • GitHub repo sydent

    Sydent: Reference Matrix Identity Server

    It wasn't designed exclusively as a federated network, tbh - we've been planning for P2P since pretty much day one; https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%... is a talk I gave in 2015 when Matrix was less than a year old on our plans to go P2P.

    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.

  • GitHub repo conduit

    One of our primary goals on the Synapse last quarter was to make it possible for a new homeserver to join Matrix HQ (a large, public room) in under 1 GB of RAM. And we did it. https://matrix.org/blog/2021/06/15/synapse-1-36-0-released

    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.

  • GitHub repo NewPipe

    A libre lightweight streaming front-end for Android.

    Have you thought about hosting your own F-Droid repository, like NewPipe does?


  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts