Hacker News Reader

Comment by dkasak | Hacker News Reader

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.

View on HN

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

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

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!

Reply on news.ycombinator.com