Hacker News Reader

Comment by throwawayKiwi9 | Hacker News Reader

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.

View on HN

This is discussed by the research team who reported these issues (I'm one of those researchers) at: 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.

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?

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/

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.

It doesn't look remotely like that, given the description the previous comment provides.

"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.

Do you think saying things like "if you follow these instructions without fail" makes Matrix security look better?

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.

Did you skim over the part where there's a toggle to strictly prevent sending messages to unauthorized devices?

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).

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?

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.

> 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?

Yes, Element is very loud about unverified device participants in an encrypted room.

Indeed:

https://nebuchadnezzar-megolm.github.io/

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

No: https://news.ycombinator.com/item?id=33018068

Yes? https://news.ycombinator.com/item?id=33024640

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".

You mean, allowed to decrypt unless following the discussed mitigations? I suspect you don't regularly use the client, which is fine, but these warnings and notifications are very annoying and essentially impossible to ignore. You are highly incentivised to resolve them. Obviously, I agree the exploit is bad. I just think the millions of users would appreciate practical discussion of the very practical mitigations instead of all the unnecessary doomsaying happening surrounding this.

The paper goes into detail on the errors and how they compare to the normal experience of using Element, but I think that discussion kind of dignifies the situation, doesn't it? We're talking about a warning that essentially says "an unauthorized person is now decrypting your messages". This isn't a reasonable thing to "warn" people about it; in a secure messenger, your job is to prevent it from happening at all.

It's weird that we're even discussing this. In Matrix, group membership is key distribution, and it's controlled by the server! That's not OK!

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?

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.

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.

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..

That's not at all true according to the paper.

I genuinely do not understand the impulse people have to rationalize stuff like this. This is a devastating research result. It might be the most damaging paper ever published on a secure messaging system; I'd have to think about that.

For what it's worth, i just did a quick survey of other secure messaging systems to see how they manage group membership. These days Signal uses zkgroups as per https://signal.org/blog/signal-private-group-system; it looks like Wire is somewhere in a transition to MLS for client-managed group membership (although historically membership looks to be entirely controlled by the server). I dread to think what WhatsApp or iMessage do (anyone know if membership is server-controlled or not?)

So yes: we should switch to client-controlled membership management, and we've already started the work to do so. However, the Matrix spec and its implementations has always been transparent that it's up to the user to verify the membership of the room - for after all, if they don't bother verifying users, then all bets will always be off anyway. For instance https://element.io/blog/e2e-encryption-by-default-cross-sign... explicitly says: "You’ve verified this user, but they have risky unverified sessions logged in! A room containing any red users is shown as red." I'm not sure this exactly counts as a research result, let alone a devastating one.

However, totally agreed that we can improve on this, and we're on the case.

Signal didn't allow servers to control group membership prior to the 2019 design!

And the zero-knowledge groups still don't give that capability to the servers, do they?

No, of course not: it's part of the premise of a secure group messenger that the server can't control the groups. Which is what makes it so incredible that Matrix screwed this up so completely.

Reply on news.ycombinator.com