Encrypt messages at rest

(#967) Feature Declined privacy security

Thread

Comment by @DarkRTA
RexSystem 1 vote 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.
Comment by @tsubus
RexSystem 1 vote 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.
Comment by @DarkRTA
RexSystem 1 vote 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.
Comment by @frolleks
RexSystem 1 vote 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.)
Comment by @DarkRTA
RexSystem 1 vote 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.
Comment by @Darker-Ink
RexSystem 1 vote 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?
Comment by @frolleks
RexSystem 1 vote 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.
Comment by @frolleks
RexSystem 1 vote 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.