5 ms·

Can you link to whatever you're referring to?

iampivot 4y ago
Maybe it's this? https://www.theregister.com/2022/09/28/matrix_encryption_flaws/ https://www.theregister.com/2022/09/28/matrix_encryption_fla...
tptacek 4y ago
https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ The cryptography itself didn't come out unscathed, but the basic nuts and bolts semantics of the system itself had devastating vulnerabilities.
- est31 4y ago
  It's a nice piece of research but I wouldn't call it a fiasco. Many parts were well engineered, they just found some edge cases that yes had devastating effects. It's the old attacker's advantage again, in security, even edge cases can get you in. Matrix is a complicated protocol and tries to do things that other messengers can't, like multi device support. The researchers also write on the website that Matrix has fixed most of the issues (4 of the listed 6 on the website), and for the remaining ones there are plans for fixes.
  - tptacek 4y ago
    All Matrix messages (in practice) are group messages, and servers control the keys for all Matrix groups. "Devastating" isn't strong enough. They killed it. It's dead. The response (or lack thereof) to this research is pretty fascinating!
    - est31 4y ago
      > The response (or lack thereof) to this research is pretty fascinating! What about: 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... > "Homeserver Control of Room Membership" – A malicious homeserver can fake invites on behalf of its users to invite malicious users into their conversations, or add malicious devices into its users accounts. However, when this happens, we clearly warn the user: if you have verified the users you are talking to, the room and user will be shown with a big red cross to mark if malicious devices have been added. Similarly, if an unexpected user is invited to a conversation, all users can clearly see and take evasive action. Therefore we consider this a low severity issue. That said, this behaviour can be improved, and we've started work on switching our trust model to trust-on-first-use (so that new untrusted devices are proactively excluded from conversations, even if you haven't explicitly verified their owner) - and we're also looking to add cryptographic signatures to membership events in E2EE rooms to stop impersonated invites. These fixes will land over the coming months.
      - tptacek 4y ago
        I think this is an amazing response. The researchers demonstrated that a malicious server can inject itself into arbitrary Matrix groups, and thus get all the keys required to decrypt messages. The response: "we'll just try to have an alert pop up that tells you the server is reading your messages". Anyways, my point is just: this is a good illustration of the phenomenon described by the root comment.
        est31 4y ago
        > The response: "we'll just try to have an alert pop up that tells you the server is reading your messages". First, they have not said they will add alerts, they say that such alerts are already there. Second, they did admit that the current situation can be improved, and have said they will add cryptographic signatures to membership events in the future. To my reading that would be precisely what the researchers were missing, aka if new folks show up, even with support of the homeserver, they still need to present a signed invite from one of the group members to be given the keys.
        shp0ngle 4y ago
        An honest question, not trying to be argumentative. If Signal server is evil and starts to MITM a communication between two parties, replacing each of the parties keys with their own keys and decrypting in the middle, both of the participants will also just get warning “the other party changed their key”, right? That was the gist of the issue of yesteryear with Guardian and WhatsApp, right? How is this in practice different? User see a warning and ignores it (as people change their phones thus their keys all the time). I’m not trying to be snarky but actually asking a question
    - bscphil 4y ago
      From the page: > In environments where cross-signing and verification are enabled, adding a new unverified user adds a warning to the room to indicate that unverified devices are present. However, it is possible for a homeserver to add a verified user to rooms without changing the security properties of the room. This allows a colluding homeserver and verified user to eavesdrop on rooms not intended for them. In other words, the warning regarding unverified devices is independent to whether the device is intended to participate in the speciﬁc room. Users may, of course, simply ignore warnings. If I'm not mistaken this is not just a "warning" - Matrix clients will actively refuse to encrypt messages to the new recipient until they are verified in this situation. The last time I seriously looked at Matrix (2019-2020ish), cross-signing and verification were essentially required for real security in chats. It sounds to me like (a) the worst case scenario vis-à-vis the "rogue server" is that things regress back to where they were in 2019, and (b) there's an issue where if everyone in a room has a rogue user validated, a rogue server can add the rogue user to a room that the user is not supposed to be invited to, without triggering a warning. This latter issue strikes me as something that should definitely be fixed (if it hasn't already been), but far from fatal for smaller chats. "They killed it. It's dead." strikes me as an enormous reach.
    - Arathorn 4y ago
      As others have pointed out… > They killed it. It's dead. …is ridiculous hyperbole. This is a debate around the “system warns you when something bad happens” versus “system stops something bad happening in the first place”. It’s like saying SSL is “killed dead” because browsers let you connect to sites with bad certs albeit with a big red warning. And much as this was addressed for SSL with HSTS etc, we’re working on the fix for Matrix. For what it’s worth, the current approach is 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... Screaming about Matrix being “killed dead” helps no-one, and risks completely sabotaging our efforts to improve open communication, just in order to score a rhetorical point.
      - tptacek 4y ago
        You're changing the protocol! Nobody has ever disputed that it's possible for the Matrix team to build a secure messaging protocol. I'm sure you can. But: have you yet? By way of example: TLS 1.0 is dead as a doornail, too. If you like, we can use a different word to capture the equivalence class here. TLS 1.0 and the current Matrix protocol: "ex-parrots". This whole situation is wild. What we're discussing on this thread is the single most impactful set of cryptographic vulnerability findings against any secure messaging system ever. And this thread is, I think, one of a very few places on the whole Internet where there's even a conversation about it. Everybody else is just rolling along as if nothing happened. If I sound mean about this, I don't mean to be. But, fair warning, I'm in full-on "wake up, sheeple" mode over this.
- pseudo0 4y ago
  It has been a bit since I read the paper, but my recollection was that the attacks weren't very practical. It's great that they responsibly disclosed issues and that Matrix tightened up the spec and implementations, but requiring a malicious homeserver plus additional preconditions made the attacks quite slim edge cases.
  - tptacek 4y ago
    In practice, all Matrix messages are group messages. Servers control group membership. That's it, that's the tweet. People have been dismissing security research with this "not very practical" epithet for as long as I've been working. Literally, at least since I got into the field. https://web.archive.org/web/20000818162612/http://www.enteract.com/~tqbf/bug-reports.html https://web.archive.org/web/20000818162612/http://www.entera...
    - pseudo0 4y ago
      My background is more in the applied end of things, not research, so I suppose that colors my perspective. But let's say I'm playing red team, and I get root on the box where my target is running their Matrix server. Practically, what can I do to extract information without setting off giant red flags? From my read of the paper the answer is "not much", since a bunch of big warnings popping up would probably alert the users that something sketchy is happening.
      - tptacek 4y ago
        If you're red-teaming a Matrix server and you own up the server, you can decrypt all the messages of all the people using that Matrix server, and you can do it trivially, just using the basic protocol messages. Users might see extra group members in their groups and they might not, depending in part on whether they're running the most current version of the software. You can decrypt all the messages. I sometimes feel like I must have read a different paper than everybody else.
        dfgdfgffd 4y ago

Maybe it's this? https://www.theregister.com/2022/09/28/matrix_encryption_flaws/ https://www.theregister.com/2022/09/28/matrix_encryption_fla...

tptacek 4y ago

https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ The cryptography itself didn't come out unscathed, but the basic nuts and bolts semantics of the system itself had devastating vulnerabilities.

est31 4y ago
It's a nice piece of research but I wouldn't call it a fiasco. Many parts were well engineered, they just found some edge cases that yes had devastating effects. It's the old attacker's advantage again, in security, even edge cases can get you in. Matrix is a complicated protocol and tries to do things that other messengers can't, like multi device support. The researchers also write on the website that Matrix has fixed most of the issues (4 of the listed 6 on the website), and for the remaining ones there are plans for fixes.
- tptacek 4y ago
  All Matrix messages (in practice) are group messages, and servers control the keys for all Matrix groups. "Devastating" isn't strong enough. They killed it. It's dead. The response (or lack thereof) to this research is pretty fascinating!
  - est31 4y ago
    > The response (or lack thereof) to this research is pretty fascinating! What about: 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... > "Homeserver Control of Room Membership" – A malicious homeserver can fake invites on behalf of its users to invite malicious users into their conversations, or add malicious devices into its users accounts. However, when this happens, we clearly warn the user: if you have verified the users you are talking to, the room and user will be shown with a big red cross to mark if malicious devices have been added. Similarly, if an unexpected user is invited to a conversation, all users can clearly see and take evasive action. Therefore we consider this a low severity issue. That said, this behaviour can be improved, and we've started work on switching our trust model to trust-on-first-use (so that new untrusted devices are proactively excluded from conversations, even if you haven't explicitly verified their owner) - and we're also looking to add cryptographic signatures to membership events in E2EE rooms to stop impersonated invites. These fixes will land over the coming months.
    - tptacek 4y ago
      I think this is an amazing response. The researchers demonstrated that a malicious server can inject itself into arbitrary Matrix groups, and thus get all the keys required to decrypt messages. The response: "we'll just try to have an alert pop up that tells you the server is reading your messages". Anyways, my point is just: this is a good illustration of the phenomenon described by the root comment.
      - est31 4y ago
        > The response: "we'll just try to have an alert pop up that tells you the server is reading your messages". First, they have not said they will add alerts, they say that such alerts are already there. Second, they did admit that the current situation can be improved, and have said they will add cryptographic signatures to membership events in the future. To my reading that would be precisely what the researchers were missing, aka if new folks show up, even with support of the homeserver, they still need to present a signed invite from one of the group members to be given the keys.
      - shp0ngle 4y ago
        An honest question, not trying to be argumentative. If Signal server is evil and starts to MITM a communication between two parties, replacing each of the parties keys with their own keys and decrypting in the middle, both of the participants will also just get warning “the other party changed their key”, right? That was the gist of the issue of yesteryear with Guardian and WhatsApp, right? How is this in practice different? User see a warning and ignores it (as people change their phones thus their keys all the time). I’m not trying to be snarky but actually asking a question
  - bscphil 4y ago
    From the page: > In environments where cross-signing and verification are enabled, adding a new unverified user adds a warning to the room to indicate that unverified devices are present. However, it is possible for a homeserver to add a verified user to rooms without changing the security properties of the room. This allows a colluding homeserver and verified user to eavesdrop on rooms not intended for them. In other words, the warning regarding unverified devices is independent to whether the device is intended to participate in the speciﬁc room. Users may, of course, simply ignore warnings. If I'm not mistaken this is not just a "warning" - Matrix clients will actively refuse to encrypt messages to the new recipient until they are verified in this situation. The last time I seriously looked at Matrix (2019-2020ish), cross-signing and verification were essentially required for real security in chats. It sounds to me like (a) the worst case scenario vis-à-vis the "rogue server" is that things regress back to where they were in 2019, and (b) there's an issue where if everyone in a room has a rogue user validated, a rogue server can add the rogue user to a room that the user is not supposed to be invited to, without triggering a warning. This latter issue strikes me as something that should definitely be fixed (if it hasn't already been), but far from fatal for smaller chats. "They killed it. It's dead." strikes me as an enormous reach.
  - Arathorn 4y ago
    As others have pointed out… > They killed it. It's dead. …is ridiculous hyperbole. This is a debate around the “system warns you when something bad happens” versus “system stops something bad happening in the first place”. It’s like saying SSL is “killed dead” because browsers let you connect to sites with bad certs albeit with a big red warning. And much as this was addressed for SSL with HSTS etc, we’re working on the fix for Matrix. For what it’s worth, the current approach is 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... Screaming about Matrix being “killed dead” helps no-one, and risks completely sabotaging our efforts to improve open communication, just in order to score a rhetorical point.
    - tptacek 4y ago
      You're changing the protocol! Nobody has ever disputed that it's possible for the Matrix team to build a secure messaging protocol. I'm sure you can. But: have you yet? By way of example: TLS 1.0 is dead as a doornail, too. If you like, we can use a different word to capture the equivalence class here. TLS 1.0 and the current Matrix protocol: "ex-parrots". This whole situation is wild. What we're discussing on this thread is the single most impactful set of cryptographic vulnerability findings against any secure messaging system ever. And this thread is, I think, one of a very few places on the whole Internet where there's even a conversation about it. Everybody else is just rolling along as if nothing happened. If I sound mean about this, I don't mean to be. But, fair warning, I'm in full-on "wake up, sheeple" mode over this.
pseudo0 4y ago
It has been a bit since I read the paper, but my recollection was that the attacks weren't very practical. It's great that they responsibly disclosed issues and that Matrix tightened up the spec and implementations, but requiring a malicious homeserver plus additional preconditions made the attacks quite slim edge cases.
- tptacek 4y ago
  In practice, all Matrix messages are group messages. Servers control group membership. That's it, that's the tweet. People have been dismissing security research with this "not very practical" epithet for as long as I've been working. Literally, at least since I got into the field. https://web.archive.org/web/20000818162612/http://www.enteract.com/~tqbf/bug-reports.html https://web.archive.org/web/20000818162612/http://www.entera...
  - pseudo0 4y ago
    My background is more in the applied end of things, not research, so I suppose that colors my perspective. But let's say I'm playing red team, and I get root on the box where my target is running their Matrix server. Practically, what can I do to extract information without setting off giant red flags? From my read of the paper the answer is "not much", since a bunch of big warnings popping up would probably alert the users that something sketchy is happening.
    - tptacek 4y ago
      If you're red-teaming a Matrix server and you own up the server, you can decrypt all the messages of all the people using that Matrix server, and you can do it trivially, just using the basic protocol messages. Users might see extra group members in their groups and they might not, depending in part on whether they're running the most current version of the software. You can decrypt all the messages. I sometimes feel like I must have read a different paper than everybody else.
      - dfgdfgffd 4y ago