Encrypt messages at rest

(#967) Feature Declined privacy security

7mo agoby RexSystem edited originally by @frolleks on GitHub

Problem

It seems that ALL messages are stored in plaintext on the server, which raises some concerns for privacy.

Proposed solution

Store the messages in an encrypted manner in the server, and the server also holds the keys for decryption and it's used when needed (e.g. moderation, or regular viewing), and it also sophisticates anybody trying to read the messages directly and purely just from the database.

Notes (optional)

This is different to E2EE, but it is similar to Telegram's Cloud Chats. From what I've found, Telegram stores the messages in an encrypted manner at rest yet they also hold the encrypted keys in the server as well. It's recommended to store the keys inside a KMS (key management system) like OpenBao/HashiCorp Vault. This would be a good default for every single chat on the platform, but maybe E2EE for DMs would be nice. I won't talk about that here, though.

History

15 comments

Sign in with Fluxer to comment and vote.

RexSystem 1 vote 1d ago

This was marked shipped, but messages are not encrypted at rest. The author withdrew the request in the thread.

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP

Other than the chats being encrypted, the media/attachments stored in those chats should be encrypted as well. But if the community has the NSFW scanning setting turned on then of course it'll get scanned before it is encrypted and then stored. And if federation gets implemented, I do hope it's identity federation because if it was message federation this feature wouldn't go as well as intended. The reason being, how would you encrypt and decrypt messages in the same community but is stored in different servers? That wouldn't go so well as I would imagine.

RexSystem 1 vote 7mo ago originally by @DarkRTA on GitHub 7 replies

To be honest, this feels like security theater because nothing stops a server admin from disabling the code and reading their own DB anyway. I guess you could get marginal security improvements in the event of a compromise but I doubt this would be possible to scale up in a secure manner.

RexSystem 1 vote 7mo ago originally by @tsubus on GitHub

yes but it would only be possible to people with access to the encryption keys, which if done correctly (on the main instance) should be just a select few people (vault admins for example), not everyone with access to the database. encryption at rest is definitely helping securing data. on smaller self hosted instances you just have to trust the owner, obviously, same as with plaintext.

RexSystem 1 vote 7mo ago originally by @DarkRTA on GitHub

You still run into the issue of the Fluxer instance itself being compromised and either leaking the keys or decrypting the content itself. Encrypting messages at rest may also be incompatible with search since the messages need to be dumped into a meilisearch instance. In general, instead of trusting that Fluxer is actually encrypting messages at rest, you should avoid sending sensitive information on a Fluxer instance outright unless you absolutely trust the people running it with access to that information. Also consider that a government warrant would require an instance operator to decrypt the data anyway.

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP

Encrypting messages at rest may also be incompatible with search since the messages need to be dumped into a meilisearch instance.

Thanks for the heads up. Like what I said in the other comment, it can call the chat encryption/decryption service to decrypt the chats that is then dumped into Meilisearch.

...you should avoid sending sensitive information on a Fluxer instance outright unless you absolutely trust the people running it with access to that information. Also consider that a government warrant would require an instance operator to decrypt the data anyway.

I would think that if federation was implemented—specifically identity federation, and the guilds are hosted in different servers, this wouldn't really be a problem. (Which somehow also renders the feature I requested useless? It's not a problem though, I'm just trying to find out whether this feature is viable or not in the long term via this discussion.)

RexSystem 1 vote 7mo ago originally by @DarkRTA on GitHub

Federation actually makes the problem of trust worse because now you need to trust random instance operators to not snoop through messages rather than a single organization. The thing about government warrants still applies too, but at a smaller scope.

RexSystem 1 vote 7mo ago originally by @Darker-Ink on GitHub

Like what I said in the other comment, it can call the chat encryption/decryption service to decrypt the chats that is then dumped into Meilisearch.

I do not believe this solves anything though, as you'd be dumping plaintext messages into Meilisearch, which makes message encryption pointless. Meilisearch becomes its own attack surface, and an attacker wouldn't even need DB access to get to the plaintext. So what would encrypting the messages in the database actually solve here?

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP

Federation actually makes the problem of trust worse because now you need to trust random instance operators to not snoop through messages rather than a single organization. The thing about government warrants still applies too, but at a smaller scope.

It really depends on what you're doing on that fluxer instance, and who hosts it. If it's someone else who hosts it, then that is a valid concern unless otherwise.

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP

> Like what I said in the other comment, it can call the chat encryption/decryption service to decrypt the chats that is then dumped into Meilisearch. I do not believe this solves anything though, as you'd be dumping plaintext messages into Meilisearch, which makes message encryption pointless. Meilisearch becomes its own attack surface, and an attacker wouldn't even need DB access to get to the plaintext. So what would encrypting the messages in the database actually solve here?

Thanks for the heads up. Another thing to point out other than Meilisearch becoming its own attack surface, although regardless if it is or not, is that plaintext access from a bad actor would still be possible as the decrypted chat would be transmitted over the network. Initially, I haven't really thought of the side effects that would affect the other services required for running Fluxer properly. Hence, I thought that this would decrease the possibility of chats being leaked. But after some consideration, this seems to add another layer of complexity which ends up being the same thing compared to if this feature wasn't implemented at all.

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP 2 replies

That is correct, but the DB only contains encrypted messages that the admin or anyone else couldn't see by default. The admin is able to see those messages—but through the admin panel where it can be decrypted. Hence, anyone with access to the DB couldn't really see anything. Unless, they have access to the server, where they could inspect the memory to extract the unencrypted data. So to fix that, another solution is to host the chat encryption/decryption service on another server, isolating itself from the others. Then, the client requests the service if there's a new message event in the gateway, and it transmits directly to the client without going through the API or the gateway.

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP

Another problem I identified is that this adds a whole layer of complexity when trying to host your own instance, but then that feature could simply be disabled by default and be enabled via a config toggle. (Which renders this feature useless?)

RexSystem 1 vote 7mo ago originally by @frolleks on GitHub OP

Another problem is that when the server that hosts this gets attacked, this feature would be rendered useless anyways.

RexSystem 1 vote 7mo ago originally by @spectrapulse on GitHub 1 reply

I don't see why adding this much complexity is necessary as it just sounds like extra steps with no amount of improved security or privacy regardless without making the entire thing E2E which has other problems. Also, This is not Telegram... It's also not WhatsApp... E2EE doesn't make sense for the platform and in my opinion for what it is trying to be it might even make it worse. If that's a concern you should either be using one of those solutions you mentioned or Matrix. This wouldn't add or improve the situation just make it more complex for no reason.

RexSystem 1 vote 2mo ago originally by @frolleks on GitHub OP

before you start raging over i initially was obsessed with telegram's transport protocol until i realized that its just a glorified tls implementation, i'll close this as messages are transported via tls anyway and encrypting messages on the server while also having keys on the server only adds complexity indeed