8 ms·

No, there are not vulnerabilities in Matrix's encryption. Homeservers are not decrypting all your messages, which is what the subheading seems to suggest. A sp

No, there are not vulnerabilities in Matrix's encryption. Homeservers are not decrypting all your messages, which is what the subheading seems to suggest. A specific client js library implementation used in Element could have been exploited to impersonate users, join rooms, recieve future messages in these rooms. Of course, everyone sees notifications and warning icons of these new sessions. Responsible disclosure occurred, flaws being patched appropriately, not found used in the wild, carry on... I applaud Matrix and Element teams for tackling the hard problems of e2e for the masses and doing a phenomenal job.

dodgerdan 4y ago
Not sure you’re correct, its still possible for a malicious home-server to add a malicious client to a user and spy on the conversation. This is because the protocol doesn’t require room management messages to be authenticated?
- dkasak 4y ago
  It's true Matrix today doesn't implement end-to-end auth for room control messages, but it's a bit of a stretch to say you can spy on conversations in this way. In a room where participants are verified with each other, you'd be warned of this with a loud red shield with an exclamation mark in the room header. Additionally, if you're extra worried about a room, there's a "Never send encrypted messages to unverified sessions in this room from this session" setting you can flip in the Element clients. That said, this can and will be improved in the future, by signing room state events and implementing TOFU (trust-on-first-use) for user identities, so that you can have a large amount of protection even before you perform manual verification with other users.
  - dodgerdan 4y ago
    > In a room where participants are verified with each other, you'd be warned of this with a loud red shield with an exclamation mark in the room header. Really? Are you sure there would be this banner in the case of a malicious device being added to an existing user in the room rather than a malicious user?
    - throwawayKiwi9 4y ago
      Yes, Element is very loud about unverified device participants in an encrypted room.
      - martinralbrecht 4y ago
        Indeed: > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users. https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/
        throwawayKiwi9 4y ago
        Looks like it would only be "likely to go unnoticed" for users that regularly disregard the massive annoying warnings about unverified devices and don't enforce verification
        tptacek 4y ago
        No: https://news.ycombinator.com/item?id=33018068 https://news.ycombinator.com/item?id=33018068
        throwawayKiwi9 4y ago
        Yes? https://news.ycombinator.com/item?id=33024640 https://news.ycombinator.com/item?id=33024640
        tptacek 4y ago
        This link doesn't say anything. The paper explains the mitigations Matrix took and their limitations, and those limitations are obvious, and have been explained here as well. All you're doing is re-stating what the limited mitigations are, and then asserting without evidence that they're adequate. But they're obviously not adequate: this is a secure group messenger that will allow unauthorized people to decrypt messages to a group, and the mitigation is "you can notice that there are unauthorized people decrypting your messages if you watch very carefully".
- deleted 4y ago
  [deleted]
martinralbrecht 4y ago
This is discussed by the research team who reported these issues (I'm one of those researchers) at: https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ > Are these attacks design flaws in the Matrix specification? > We will explain this one by one by using the name of the attacks previously defined: > a. Simple confidentiality break: The root cause of this attack is the fact that room management messages are not authenticated, which is a design flaw in the protocol itself, as no mechanism was specified for authentication of such messages. > b. Attack against out-of-band verification: This attack exploits an insecure implementation choice enabled by a design flaw in the specification as there is no domain separation enforced there. > c. Semi-trusted impersonation: This is mostly implementation bug supported by a lack of guidance on the processing of incoming key shares in spec. > d. Trusted impersonation: This is an implementation error as no check is performed to check whether Olm is used for encryption or not. > e. Impersonation to confidentiality break: This is an implementation error as no check is performed to check whether Olm is used for encryption or not. > f. IND-CCA break: This theoretical attack exploits a protocol design flaw. On the viability of the discussed countermeasure: > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users.
- throwawayKiwi9 4y ago
  Thanks for your work! So a user can mitigate this by keeping encryption enabled and also enabling the option to never send encrypted messages to unverified sessions?
  - martinralbrecht 4y ago
    Unfortunately, it is not quite so simple: > Does this mean that Matrix does not provide confidentiality and/or authentication? > Matrix and its implementations can, after today’s fixes, provide confidentiality and authentication assurances against malicious homeservers, if users act as follows. Each user must enable cross-signing and perform out-of-band verification with each of their own devices, and with each user they interact with.2 They must then remain vigilant: any warning messages or icons must be spotted and investigated. In the Element user interface, this requires checking the room icon and each individual message they receive (in some cases, past messages can retroactively receive a warning). Note that such warnings could be expected behaviour (for example if the message was decrypted using a server-side Megolm backup or through the “Key Request protocol”). Users would need the expertise to investigate these warnings thoroughly and, if an issue is found, recover from it. If you follow these instructions without fail, Matrix can provide you with confidentiality and authentication. > This places an unnecessary burden on users of Matrix clients, limits the user base to those with an understanding of the cryptography used in Matrix and how it is used therein, and is impractical for daily use. The burden this places on users is unnecessary and the result of the design flaws we highlight in our work (this is our “Simple confidentiality break” attack). Whilst this issue will persist after today’s fixes, a remediation is planned by the Matrix developers for a later date. > Some of our other attacks against Matrix’s flagship client Element are based on implementation flaws and, thus, were able to break its confidentiality and authentication guarantees even when the steps above were followed (prior to today’s patches). As of today, most of these issues should be fixed (see above), but we have not independently verified this. The Matrix developers report that other clients are not affected but, similarly, we have not independently verified this. https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/
tptacek 4y ago
The flaws are in fact not being patched appropriately. For instance: the project told the researchers that they were "accepting the risk" that malicious homeservers could spoof group memberships. In Matrix, group membership equates to the ability to decrypt messages; that's an extremely weird "risk" to accept, isn't it?
- dkasak 4y ago
  The risk being accepted is that a homeserver can currently add members to the group with the group being notified of this. This risk will be removed completely once TOFU and signed control events are implemented, which is planned (and was planned before this research). It's just more work than could fit in the disclosure timeline, especially because it's a large change needing ecosystem coordination.
  - tptacek 4y ago
    I don't think "the group being notified" that an unauthorized member can decrypt all their messages is quite the mitigation that Matrix advocates think it is. This is the fundamental task of any secure group messenger. It has really one job: don't let unauthorized people read messages for the group. Here, Matrix has apparently accepted the risk that their group messenger can't do that job if the server is compromised. If you know where to look and your group is small enough, you can constantly watch to see if your homeserver has decided to stop protecting your group, but either way: your homeserver can spontaneously decide to stop protecting your group. Matrix, you had one job! At the point where you accept this risk, you might as well just use Slack.
    - throwawayKiwi9 4y ago
      Your suggesting to use Slack, where a similar compromise would reveal your entire account message history.. ? Just enforce proper key verification for now and you're fine..
      - tptacek 4y ago

dodgerdan 4y ago

Not sure you’re correct, its still possible for a malicious home-server to add a malicious client to a user and spy on the conversation. This is because the protocol doesn’t require room management messages to be authenticated?

dkasak 4y ago
It's true Matrix today doesn't implement end-to-end auth for room control messages, but it's a bit of a stretch to say you can spy on conversations in this way. In a room where participants are verified with each other, you'd be warned of this with a loud red shield with an exclamation mark in the room header. Additionally, if you're extra worried about a room, there's a "Never send encrypted messages to unverified sessions in this room from this session" setting you can flip in the Element clients. That said, this can and will be improved in the future, by signing room state events and implementing TOFU (trust-on-first-use) for user identities, so that you can have a large amount of protection even before you perform manual verification with other users.
- dodgerdan 4y ago
  > In a room where participants are verified with each other, you'd be warned of this with a loud red shield with an exclamation mark in the room header. Really? Are you sure there would be this banner in the case of a malicious device being added to an existing user in the room rather than a malicious user?
  - throwawayKiwi9 4y ago
    Yes, Element is very loud about unverified device participants in an encrypted room.
    - martinralbrecht 4y ago
      Indeed: > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users. https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/
      - throwawayKiwi9 4y ago
        Looks like it would only be "likely to go unnoticed" for users that regularly disregard the massive annoying warnings about unverified devices and don't enforce verification
        tptacek 4y ago
        No: https://news.ycombinator.com/item?id=33018068 https://news.ycombinator.com/item?id=33018068
        throwawayKiwi9 4y ago
        Yes? https://news.ycombinator.com/item?id=33024640 https://news.ycombinator.com/item?id=33024640
        tptacek 4y ago
        This link doesn't say anything. The paper explains the mitigations Matrix took and their limitations, and those limitations are obvious, and have been explained here as well. All you're doing is re-stating what the limited mitigations are, and then asserting without evidence that they're adequate. But they're obviously not adequate: this is a secure group messenger that will allow unauthorized people to decrypt messages to a group, and the mitigation is "you can notice that there are unauthorized people decrypting your messages if you watch very carefully".
deleted 4y ago
[deleted]

martinralbrecht 4y ago

This is discussed by the research team who reported these issues (I'm one of those researchers) at: https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ > Are these attacks design flaws in the Matrix specification? > We will explain this one by one by using the name of the attacks previously defined: > a. Simple confidentiality break: The root cause of this attack is the fact that room management messages are not authenticated, which is a design flaw in the protocol itself, as no mechanism was specified for authentication of such messages. > b. Attack against out-of-band verification: This attack exploits an insecure implementation choice enabled by a design flaw in the specification as there is no domain separation enforced there. > c. Semi-trusted impersonation: This is mostly implementation bug supported by a lack of guidance on the processing of incoming key shares in spec. > d. Trusted impersonation: This is an implementation error as no check is performed to check whether Olm is used for encryption or not. > e. Impersonation to confidentiality break: This is an implementation error as no check is performed to check whether Olm is used for encryption or not. > f. IND-CCA break: This theoretical attack exploits a protocol design flaw. On the viability of the discussed countermeasure: > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users.

throwawayKiwi9 4y ago
Thanks for your work! So a user can mitigate this by keeping encryption enabled and also enabling the option to never send encrypted messages to unverified sessions?
- martinralbrecht 4y ago
  Unfortunately, it is not quite so simple: > Does this mean that Matrix does not provide confidentiality and/or authentication? > Matrix and its implementations can, after today’s fixes, provide confidentiality and authentication assurances against malicious homeservers, if users act as follows. Each user must enable cross-signing and perform out-of-band verification with each of their own devices, and with each user they interact with.2 They must then remain vigilant: any warning messages or icons must be spotted and investigated. In the Element user interface, this requires checking the room icon and each individual message they receive (in some cases, past messages can retroactively receive a warning). Note that such warnings could be expected behaviour (for example if the message was decrypted using a server-side Megolm backup or through the “Key Request protocol”). Users would need the expertise to investigate these warnings thoroughly and, if an issue is found, recover from it. If you follow these instructions without fail, Matrix can provide you with confidentiality and authentication. > This places an unnecessary burden on users of Matrix clients, limits the user base to those with an understanding of the cryptography used in Matrix and how it is used therein, and is impractical for daily use. The burden this places on users is unnecessary and the result of the design flaws we highlight in our work (this is our “Simple confidentiality break” attack). Whilst this issue will persist after today’s fixes, a remediation is planned by the Matrix developers for a later date. > Some of our other attacks against Matrix’s flagship client Element are based on implementation flaws and, thus, were able to break its confidentiality and authentication guarantees even when the steps above were followed (prior to today’s patches). As of today, most of these issues should be fixed (see above), but we have not independently verified this. The Matrix developers report that other clients are not affected but, similarly, we have not independently verified this. https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/

tptacek 4y ago

The flaws are in fact not being patched appropriately. For instance: the project told the researchers that they were "accepting the risk" that malicious homeservers could spoof group memberships. In Matrix, group membership equates to the ability to decrypt messages; that's an extremely weird "risk" to accept, isn't it?

dkasak 4y ago
The risk being accepted is that a homeserver can currently add members to the group with the group being notified of this. This risk will be removed completely once TOFU and signed control events are implemented, which is planned (and was planned before this research). It's just more work than could fit in the disclosure timeline, especially because it's a large change needing ecosystem coordination.
- tptacek 4y ago
  I don't think "the group being notified" that an unauthorized member can decrypt all their messages is quite the mitigation that Matrix advocates think it is. This is the fundamental task of any secure group messenger. It has really one job: don't let unauthorized people read messages for the group. Here, Matrix has apparently accepted the risk that their group messenger can't do that job if the server is compromised. If you know where to look and your group is small enough, you can constantly watch to see if your homeserver has decided to stop protecting your group, but either way: your homeserver can spontaneously decide to stop protecting your group. Matrix, you had one job! At the point where you accept this risk, you might as well just use Slack.
  - throwawayKiwi9 4y ago
    Your suggesting to use Slack, where a similar compromise would reveal your entire account message history.. ? Just enforce proper key verification for now and you're fine..
    - tptacek 4y ago