synapse allows sending of unecrypted messages to encrypted rooms

[telmich]

Description

When posting a message wtih m.room.message type to synapse to a room that is encrypted, synapse accepts the message and stores it.

Steps to reproduce

Post an unencrypted message to an encrypted room.

Homeserver

any

Synapse Version

1.115.0

Installation Method

Docker (matrixdotorg/synapse)

Database

postgresql

Workers

Single process

Platform

Kubernetes

Configuration

Relevant log output

-

Anything else that would be useful to know?

Expected behaviour is after m.room.encryption unencrypted messages are rejected.

[telmich]

Element-web does show the unencrypted message with a warning sign, but conceptually I think synapse should not accept it after m.room.encryption has been sent to the room.

[anoadragon453]

Personally I consider this a feature rather than a bug. It allows for trusted bots (or simply a shell script with a single curl command) that don't otherwise support encryption to still post into the room.

If you really want to disallow this however, just set the power level for m.room.message to Admin only.

[telmich]

@anoadragon453 That does not make any sense, imho, as it does not fix the problem:

• swtiching to power level up Admin only -> all admins can send unencrypted messages -> same problem

I think with the current synapse implementation it is impossible to create encrypted only rooms and that opens up for backdoors/hacks in clients. Assume the following:

A client is compromised and patched to send unencrypted messages to an "encrypted room". Everyone will read the messages and most users will assume that they are encrypted, because the room is encrypted. A small exclamation mark will be overseen my most users.

Instead of adding another UI hint, I think, if not the default, synapse should at least have a feature to forbid sending unencrypted messages to rooms that are intended to be encrypted only.

Thus I'd ask to reopen this issue in the spirit of having a secure and trustworthy system.

[anoadragon453]

Ah, I better understand the attack you're describing now. This may be addressed by the upcoming "Invisible Crypto" work that's currently undergoing in the spec...

However, a compromised client could also just upload a user's text separately of sending a message... Or, they could send events with type that aren't rendered by most clients, containing the cleartext. Most bets are off once a client is running untrusted code.