> 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.
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?
> 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.
It still looks like users that enable the previously mentioned option and/or verify sessions accordingly are fine. I'm just trying to clarify a simple guideline for users looking to continue using Matrix securely with confidence.
"if you follow these instructions without fail, Matrix can provide you with confidentiality and authentication." I was hoping the researchers could clarify these simple mitigation instructions to protect users, assuming they already know how to use Element.
Yes. I have used Matrix professionally for years and it's pretty simple for me to understand and follow what is unnecessarily editorialized here to keep my conversations safe. I don't understand why this language is not being simplified to keep Matrix users safe, as that should be the highest goal of this entire situation.
The typical standard for a system that purports to offer cryptographically secure communication to end-users is that it does it by default rather than 'only does it if the user does these specific things otherwise it doesn't'. This isn't some controversial thing or topic of particularly serious debate.
I agree wholeheartedly and this is why I use Matrix. The fact that a vulnerabilitiy of this magnitude can largely be defeated with precautions, albeit non ideal, are a real testament to the power of e2e. Hopefully we will see the fixes these non-default settings recommendations very soon.
You keep saying that this vulnerability can be defeated by carefully examining warnings. That's simply not true. The vulnerability is that the server, which you're not supposed to trust, can allow unauthorized people to decrypt your messages. The fact that you get a warning when unauthorized people are decrypting your messages is not a "defeat" of the vulnerability!
The bug is that you're owned, not that you didn't get an alert saying that you're owned.
No, I did not. There are like 7 different horrible vulnerabilities in this paper, and you're talking about a different one (the one where the server can add new devices to people's accounts!) than I am (the one where the server can add random people to your channel, whether they're verified or not).
> 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.