4 ms·

We (the matrix team) addressed the implementation vulnerabilities discussed here back in September: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en

We (the matrix team) addressed the implementation vulnerabilities discussed here back in September: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en.... The only pending work is switching to TOFU (trust on first use) and client-controlled room membership. Currently users get warned if a malicious device or user gets added to a room by a malicious server (assuming users in the room are verified). However, rather than warning, we could block it outright - but this is nontrivial as it means clients have to independently replicate the group membership semantics the server currently handles, which are complicated in a decentralised environment. https://github.com/matrix-org/matrix-spec-proposals/blob/fayed/cryptographic-membership/proposals/3917-cryptographic-membership.md https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift membership to be controlled clientside, and https://github.com/matrix-org/matrix-spec-proposals/blob/fayed/tofu/proposals/3834-tofu.md https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift to TOFU. Meanwhile, this work is blocked behind switching to matrix-rust-sdk-crypto across Element on Web, iOS and Android, so we only fix this in one (audited) place - and can also build on the newly audited vodozemac implementation of Matrix’s encryption: https://matrix.org/blog/2022/05/16/independent-public-audit-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption https://matrix.org/blog/2022/05/16/independent-public-audit-.... This work is going well though - I for one have been dogfooding ElementR (Element with rust-sdk-crypto) on iOS as my daily driver for the last week, and we should be releasing it shortly.

dodgerdan 4y ago
To paraphrase another comment on this; if I have to trust the server for Matrix E2EE to work, why don’t I just use Slack? The whole point of E2EE is so you don’t have to trust the server. And a “warning” that says something like “your group chat has been compromised by someone with access to the server or it might just be bob bought a new phone” is laughable as a status quo.
- Arathorn 4y ago
  The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever. Then, if you've done that, and an unverified device is added to the conversation, the warning shows up and explicitly means "your group chat has been compromised" - just like a big red TLS warning on a webpage means "this certificate is bad". It does *NOT* mean that "it might just be bob bought a new phone"; if bob bought a new phone, he'll have verified it when he logged in, and so the warning doesn't show up. Anyone who actually uses Matrix will be familiar with the fact that it's pretty rare to see a big red X on a user who you've verified, and when it happens, you go ping them to ask wtf is going on - much like you'd ping the webmaster of a site whose TLS certificate is bad. This is why the Matrix community is not up in arms about this "vulnerability" - it is literally following the intended design, right from the point that we announced verification back in https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/ https://element.io/blog/e2e-encryption-by-default-cross-sign.... Now, this design can absolutely be improved on - at the least, we could go back to freezing the room whenever there's an unverified device, forcing the users to decide how to flush out the old device. Or we could switch to TOFU, and block unverified devices by default. But we've chosen to prioritise migrating the clients onto a single E2EE codebase (matrix-rust-sdk-crypto) first, so we do that work in a single place, rather than in quadruplicate across matrix-{js,ios,android,rust}-sdk.
  - dodgerdan 4y ago
    > The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever. I’ve read your blog posts and this comment, congratulations it seems to have satisfied most people. Howerver it is NOT the same as Signal. Signal servers cannot just add a device to a group chat. I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes. To me Matrix isn’t secure, the organizations responses to these disclosures has been poor and the “fixes” weak.
    - Arathorn 4y ago

dodgerdan 4y ago

To paraphrase another comment on this; if I have to trust the server for Matrix E2EE to work, why don’t I just use Slack? The whole point of E2EE is so you don’t have to trust the server. And a “warning” that says something like “your group chat has been compromised by someone with access to the server or it might just be bob bought a new phone” is laughable as a status quo.

Arathorn 4y ago
The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever. Then, if you've done that, and an unverified device is added to the conversation, the warning shows up and explicitly means "your group chat has been compromised" - just like a big red TLS warning on a webpage means "this certificate is bad". It does *NOT* mean that "it might just be bob bought a new phone"; if bob bought a new phone, he'll have verified it when he logged in, and so the warning doesn't show up. Anyone who actually uses Matrix will be familiar with the fact that it's pretty rare to see a big red X on a user who you've verified, and when it happens, you go ping them to ask wtf is going on - much like you'd ping the webmaster of a site whose TLS certificate is bad. This is why the Matrix community is not up in arms about this "vulnerability" - it is literally following the intended design, right from the point that we announced verification back in https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/ https://element.io/blog/e2e-encryption-by-default-cross-sign.... Now, this design can absolutely be improved on - at the least, we could go back to freezing the room whenever there's an unverified device, forcing the users to decide how to flush out the old device. Or we could switch to TOFU, and block unverified devices by default. But we've chosen to prioritise migrating the clients onto a single E2EE codebase (matrix-rust-sdk-crypto) first, so we do that work in a single place, rather than in quadruplicate across matrix-{js,ios,android,rust}-sdk.
- dodgerdan 4y ago
  > The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever. I’ve read your blog posts and this comment, congratulations it seems to have satisfied most people. Howerver it is NOT the same as Signal. Signal servers cannot just add a device to a group chat. I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes. To me Matrix isn’t secure, the organizations responses to these disclosures has been poor and the “fixes” weak.
  - Arathorn 4y ago