Better handling of misconfigured encryption in room

[BillCarsonFr]

A room is set as encrypted when a state event of type m.room.encryption is set.
There is no UI to update such state events, but a state event can be sent by a room admin using devtools for example (user with enough Power Level to send state events)

Currently some clients ignores m.room.encrytion state events when there is already one in the room, but it's problematic because new logins will only see the latest resolved state, and woud have to resolve the full history of that state to decide what to with that room.

We decided to follow a more pragmatic approach:

• If there is a m.room.encryptionstate event, consider the room as e2e (no matter what the content of the event is)
• If the m.room.encryption is malformed or refer to an unknown algorithm, then consider the encryption as missconfigured and block sending in that room (until fixed by a state update)
• If the event is correct and using megolm algorithm (m.megolm.v1.aes-sha2), then the room is correctly configured and the user can send messages

For live m.room.encryption state event received, never ignore and store value:

- If an invalid `m.room.encryption` is received -> Mark the room as encrypted but Deny sending
- If a valid `m.room.encryption` is received with unknown alg -> Same \(Mark the room as encrypted but Deny sending\)

=> If a follow up valid m.room.encryption with correct alg is received, client should repair the room and allow sending.

(FTR currently on web, if encryption is using an unknwon algorithm sending in the room would be broken. Each event would fail to send, so better to deny sending)

UX to deny sending when encryption is misconfigured

Should use the same ux system as when the user can't send due to power levels (hiding / disabling text composer):

^ Sample on android (copy and icon to be defined)

A specific icon should be displayed on top bar to reflect misconfigured state

The encryption tile in timeline should also reflect the state

We should no more see ignored encryption tiles

The settings screen should also reflect that state, and offer a action/button for admin that would fix encryption)

^ Icons / Copy to be defined via design

Dev issues:

• Better handling of misconfigured room encryption element-android#4711
• Better handling of misconfigured room encryption  element-ios#5322
• Better handling of misconfigured room encryption element-web#20247
• Better handling of misconfigured encryption in room  hydrogen-web#620

[BillCarsonFr]

@bwindels -> tagging you for handling in hydrogen

[amshakal]

Here are the proposed designs:

Link to Figma: https://www.figma.com/file/TPa7nvu46zg2bpIscmD64c/Untitled?node-id=1%3A33

[blaa]

I'm uncertain, but this looks closest to a fatal encryption issue I've encountered recently, so I'll chip in instead of creating new issue (unless instructed differently):

• I've got 3 logged in accounts (2x android, 1x desktop/flatpak).
• Own server.
• Talking with a friend using mobile element on android.

Suddently one of androids starts sending UNENCRYPTED messages (also: dropped info about channel title, doesn't recognize itself as channel administrator, still decrypts other devices).

This seems quite fatal because the user is not informed at all that he suddently dropped out of e2e and starts sending unencrypted messages. Other sessions (mine, and my friend's) started showing the messages as unencrypted.

Logging out and relogin on the broken device fixed the issue.

I kind of believe that the channel state was invalid, but on the CLIENT side, not on the server side. So it might not be 100% related. Still I believe client should fallback into "Ok, I won't let you send unencrypted messages in channel that had encryption enabled at any point". Especially server-side attacker shouldn't be able to downgrade e2e encryption for any participants by crafting invalid state message.

I have screenshots of the issue if helpful. But thats mostly inconsistent warning icons "unencrypted" on two devices. Viewing source of the messages on any device, revealed them as unencrypted.

[dkasak]

So, yes, we also need to ensure that none of the clients can have their encryption disabled if the m.room.encryption state event disappears. That is, once a valid m.room.encryption event was received by a client, encryption should never be disableable, regardless of what the server sends afterwards.

Element Web/Desktop should already be doing this partially, but it shouldn't happen even if the event is redacted. We need to verify whether this kind of protection exists in each of Element's clients and implement it if it does not.

[capocasa]

I reported one of the issues regarding this, just wanted to add the end user perspective here- I was happily chatting away noticing nothing unusual on my android phone, then I continued the conversation on element web and all my messages of that day in one of the rooms had the unencrypted-icon on it. With nothing else to go on, my trust in element was temporarily completely undermined.

So I reported the bug on github and thankfully it got triaged really well, and the engineers were so kind as to explain really well what happened.

I'm fine for everyday use, but would probably now hesitate to use element in areas where there is tangible danger, which I previously would have assumed to be possible. Having there are some kind of consistently applied technical safeguard to this type of situation would alleviate that.

Thank you all for your continued work on element!

[blaa]

I had similar experience. I'm looking at element+matrix as a replacement for signal and/or XMPP+Pidgin pair. Both of those handle encryption in a more "trustful" way (pidgin using OTR), but lack different things (xmpp multiple client support, signal having your own server easily settable, even for airgapped architectures, etc.).

I've also reported that currently it's impossible in element to revoke a trust for a user/device even if element site in FAQs says otherwise "if you suspect that a trusted device has fallen into the wrong hands, you can revoke that trust and remove its access to the ongoing encrypted conversation.")

[capocasa]

I have further attached my initial proposal to the matrix organization for consideration at the spec level, and was received positively in spirit, but it may be overly broad to solve this on the matrix level rather than at the spec level.

I have placed my suggestion for a spec change (knowing it is a bit of a high level, since I am unfamiliar with the usual way to make specifications for matrix or submit proposals for element, but I hope the high level meaning is clear enough and could be reasonably well translated into something that could be used for design and development purposes)

--- reproduced from matrix/#3701 --

Element-branded clients MUST confirm from three different information sources that an unencrypted message was indeed intended to be sent unencrypted. They MUST prevent immediate sending of the message, and can either prevent sending altogether or ask for confirmation. Information sources, of which three must be checked, can be: Room encryption state, encrypted messages present in the room, room room type set to private.

Element-branded clients MUST make every possible effort to ensure that the information relied upon to make the determination that a message may be sent unencrypted is in a fresh state and not stale.

Element-branded clients MUST determine whether messages sent in a room will be sent encrypted or unencrypted before an attempt is made by the user to send a message. Further, Element-branded clients MUST make it obvious to the user whether a composed message is going to be sent encrypted or unencrypted, through use of an appropriate GUI element, such as an open/closed lock icon of obviously different graphics and colors in the send button itself, or something equivalently obvious.

Element-branded clients MUST NOT under any circumstances send a message to a room with a different encryption state than the GUI-element announced, as this is the crucial point of trust for the user. Ideally, the same code procedure that updates the icon state should set the encrypted/unencrypted determination in a protected variable which is then read by the sending procedure before sending.

--

I would further add an additional one for consideration here at element meta

Element-branded clients MUST enable end-to-end encryption by default wherever there is an expectation of privacy, e.g. non-public rooms or direct messages. Element-branded clients SHOULD NOT allow disabling of end-to-end encryption in options.

Thank you for your consideration.

[BillCarsonFr]

We keep here discussion around misconfiguration of encryption (handling of m.room.encryption state events, rooms with several encryption state).
Bugs with broken local state are handled separatly

[blaa]

It just happened again in the same room, but this time to my friend and not myself. He had 3 logged in sessions and everything was fine. Mac version requested an update in the night and then in the morning android was sending unencrypted messages.

https://temp.thera.be/element-e2e-fail.png screen might help.

Relogging the android version fixed the issue.