3 ms·

Also, malicious homeservers can add fake devices to rooms and the default client configuration is to send encrypted data to untrusted devices (and I have never

by cyphar 1y ago

Also, malicious homeservers can add fake devices to rooms and the default client configuration is to send encrypted data to untrusted devices (and I have never seen anyone opt-in to "don't send to untrusted devices" because even with device signing, it breaks usability in most group chats). Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues. Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.

AstralStorm 1y ago
Adding fake devices doesn't do anything since the homeserver doesn't have your key. It literally can't do that. If you're sending encrypted to untrusted on a public room, you're trusting the homeserver. It's literally like trusting a web server that it won't MITM you.
- cyphar 1y ago
  If a homeserver adds a fake device to an existing user of a room, the default behaviour of Matrix clients is to implicitly trust that device and send new messages to it. So any homeserver used by any user in a room could read future messages transparently and without any indication to the user that this is happening (unless all users in the room have opted-in to the "do not send to untrusted devices" knob). This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
  - Arathorn 1y ago
    Ugh, yes - i'd made the mental leap that https://github.com/element-hq/element-meta/issues/2700 https://github.com/element-hq/element-meta/issues/2700 had finished rolling out, whereas it looks like it's now delayed until October due to having to wait for the ecosystem to catch up. my bad.
    - cyphar 1y ago
      To be clear -- I am very glad that this issue is finally being resolved after such a long time. I just wish that there had been a larger warning about it from the start (especially once E2EE stopped being marked as experimental).
Arathorn 1y ago
I’ve never said this is “only an issue for malicious homeservers”. I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.
- cyphar 1y ago
  And you need to opt-in to the global-and-off-by-default "don't send to unverified devices" setting, right? Or is it no longer the case that even if you verify a user, unverified devices of that users' account will still receive peer keys and messages? (The description of the global knob implies that this still is the case. I don't have time to test this at the moment.)

by cyphar 1y ago

AstralStorm 1y ago

Adding fake devices doesn't do anything since the homeserver doesn't have your key. It literally can't do that. If you're sending encrypted to untrusted on a public room, you're trusting the homeserver. It's literally like trusting a web server that it won't MITM you.

cyphar 1y ago
If a homeserver adds a fake device to an existing user of a room, the default behaviour of Matrix clients is to implicitly trust that device and send new messages to it. So any homeserver used by any user in a room could read future messages transparently and without any indication to the user that this is happening (unless all users in the room have opted-in to the "do not send to untrusted devices" knob). This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
- Arathorn 1y ago
  Ugh, yes - i'd made the mental leap that https://github.com/element-hq/element-meta/issues/2700 https://github.com/element-hq/element-meta/issues/2700 had finished rolling out, whereas it looks like it's now delayed until October due to having to wait for the ecosystem to catch up. my bad.
  - cyphar 1y ago
    To be clear -- I am very glad that this issue is finally being resolved after such a long time. I just wish that there had been a larger warning about it from the start (especially once E2EE stopped being marked as experimental).

Arathorn 1y ago

I’ve never said this is “only an issue for malicious homeservers”. I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.

cyphar 1y ago
And you need to opt-in to the global-and-off-by-default "don't send to unverified devices" setting, right? Or is it no longer the case that even if you verify a user, unverified devices of that users' account will still receive peer keys and messages? (The description of the global knob implies that this still is the case. I don't have time to test this at the moment.)