Documentation about implications of functionality of E2E-encryption

[Gummikavalier]

Description:

Rocket.Chat needs more documentation about the implications and possible attack vectors for the implementation of the E2E-encryption feature to make sure users and maintainers of services would better understand them and plan their systems accordingly.

Steps to reproduce:

Search information regarding E2E-encryption at https://docs.rocket.chat.

Expected behavior:

Depiction of how E2E-encryption works in Rocket.Chat

Actual behavior:

There is no documentation

Additional context

Previous discussions about the E2E-implementation (stale):
#14829
#16153

This is a documentation request and suggestion about limitations of current E2E-encryption functionality to make sure that both maintainers and users of Rocket.Chat would understand how well they are protected when they are using this feature.

Please note that because there is no documentation currently available everything below is disputable until the developers confirm or deny these points themselves. It is known that both E2E-encryption private and public keys are saved into the database for easier deployment on the clients.

We did some testing and current implementation seems to work in a way that when one E2E-private key is completely reset and gets a new public key, following happens:

• At first all messages are invisible or in encrypted format on encrypted channel for the user who reset their key. User cannot send messages at this point on an encrypted channel.
• When any other existing members on the channel sends a new message to it, the client end encrypts all messages on the channel again using the new public key of the member who reset the key.
• After the new public key has been added to the channel chain of keys on the channel, user with the new key can again read all messages on the channel, as well as send new messages on it.

Other notes regarding E2E-encryption in Rocket.Chat:

• Unlike in really strong E2E-encryption implementations, private keys are saved into the database on the server directly. This is probably for the ease of use for the users; doing it any other way would mean transferring keys between multiple clients manually by the users themselves.
• The password of the private key (aka E2E-password) is likely to be saved into the memory of client (browser or actual client), and not on the server to protect private keys from malicious administrators or hackers stealing the database and private keys along with it.
• Because the private keys are protected only by their passwords, they can be subjected to bruteforcing by administrators or hackers. Bruteforcing can crack any weak passwords in a matter of minutes.
• Because all messages on an encrypted channel are encrypted with all public keys of its members, the weakest link for the channel's security is always the weakest private key password of its all members.

E2E-implementation protects the user in following situations:

1. Database has been stolen from the server. There could not be open clients with working private keys online at that point to decrypt the messages on the channels.
2. Messages in the transit between client and server get extra encryption layer on top of regular TLS encryption of the server and client communications.
3. Mobile notification system based on the Firebase cloud service as well as Rocket.Chat gateway service (hosted by the developers of Rocket.Chat and default gateway for non branded Rocket.Chat mobile app) through which the messages previously went in plain text (excluding TLS of the network connections).

E2E-implementation does not protect users in the following situations:

1. Malicious administrators. They can either reset the keys (and passwords) directly from the database, or just reset the password for the user, log in, reset the e2e-key in user's preferences. After that they'll only need to wait that any of the existing channel members sends a new message. At this point malicious admin's new public key based on its new private key and password will be taken into use on the channel, revealing all (new and old) encrypted messages on it.
2. Malicious administrators or hackers subject keys in the database to a brute-forcing attack, at which point all too weak keys would be found, compromising all channels the owners of these keys would be members of.

It is a compromise between usability and security:

As long as the automatic reset key functionality exists OR private keys are saved into the database OR old messages are rerolled automatically using new public keys, there cannot be protection against malicious administrators.

Also nothing protects against malicious administrators with web apps in general anyway: Since the web client code is downloaded from the server to the browser, it would be somewhat trivial to build such version of Rocket.Chat that would save the private key passwords, or even steal the private keys if weren't already in the database, instead of managing them just locally on the browser client.

To get perfect security would mean that private keys or their passwords would never be saved into the web browser, meaning users would have to use audited versions of such clients that don't download any code from any sources actively. Therefore it is reasonable that the attack vector of malicious administrators is ignored in the E2E-implementation. This just needs to be documented in a way that everyone understands the reasons and the implications these compromises pose for their security.

[close-issue-app]

This issue was closed because it does not use our bug report issue template.

Please make sure to use it and fill it as much as you can so we can provide better and faster support.

The following sections must not be removed, or else the BOT will close it immediately again:

• Steps to reproduce
• Expected behavior
• Actual behavior
• Server Setup Information