VPS encryption
from ouch@lemmy.world to linux@lemmy.ml on 15 Sep 2024 14:41
https://lemmy.world/post/19796769

How would you protect files of a VPS (Virtual Private Server) from snooping by the service provider?

#linux

threaded - newest

NegativeLookBehind@lemmy.world on 15 Sep 2024 14:48 next collapse

LUKS

VPN

Encrypt sensitive files

boredsquirrel@slrpnk.net on 15 Sep 2024 15:41 next collapse

So how do you decrypt the LUKS vault when you have no sshd running as that thing is not up yet?

NegativeLookBehind@lemmy.world on 15 Sep 2024 15:45 next collapse

Do VPSs typical give you LOM? Honest question. Maybe LUKs isn’t good if you can’t console in.

Zikeji@programming.dev on 15 Sep 2024 16:08 next collapse

LUKS, or anything that relies on the server encrypting, is highly vulnerable (see schizo@forum.uncomfortable.business’s response).

Your best bet would be encrypting client side before it arrives on the server using a solution like rclone, restic, borg, etc.

boredsquirrel@slrpnk.net on 15 Sep 2024 16:50 collapse

Yes. No proof their LUKS prompt isnt tampered with

lud@lemm.ee on 15 Sep 2024 22:15 collapse

Yeah, at least the ones I used have some kind of console/terminal you can use and often you can access BIOS and reinstall the OS if you want.

fuzzy_feeling@programming.dev on 15 Sep 2024 16:50 next collapse

you can but an ssh server in your initramfs.
dropbear-initramfs i guess was the name in debian.

boredsquirrel@slrpnk.net on 15 Sep 2024 16:53 collapse

Pretty cool!

Android and ChromeOS both also just use fuse for userspace (and user-files) encryption. This could totally be used too.

But of course, if something is not on your RAM it is not safe

JubilantJaguar@lemmy.world on 15 Sep 2024 19:58 collapse

Another option: encrypt a sparse file rather than a disk volume. Mount the file to local filesystem and open and close it there.

possiblylinux127@lemmy.zip on 15 Sep 2024 19:02 collapse

That only works if the decryption is happening on hardware you control. You can not trust any part of the VPS including the memory and CPU

schizo@forum.uncomfortable.business on 15 Sep 2024 14:55 next collapse

Depends on your threat model and actual realistic concerns.

Ultimately, if it comes down to it, there’s very little you can do that’s failsafe and 100% guaranteed: the provider has access to your disk, all data in your instances RAM (including encryption keys), and can watch your processes execute in real time and see even the specific instructions your vCPU is executing.

Don’t put illegal shit on hardware you do not physically own and have physical control over, and encrypt everything else but like, if the value of your shit is high enough, you’re fucked if you’re using someone else’s computer.

trollblox_@programming.dev on 15 Sep 2024 15:06 next collapse

I like this answer

delirious_owl@discuss.online on 16 Sep 2024 13:06 collapse

I mean, if you’re doing to do illegal shit (eg journalism), it is best done on a VPS. This is what basically every military and cyber mercenary orgs do.

Just make sure you only log into the box over Tor, and configure it to only pass data out over Tor. Use it as a jump box. Even if they compromise it, it should tell them nothing about you useful for attribution

[deleted] on 15 Sep 2024 15:06 next collapse

.

possiblylinux127@lemmy.zip on 15 Sep 2024 18:59 next collapse

Intel is pushing there “encrypted enclave” which supposedly protects the host from being able to read or write guest memory. However, I have serious doubt as it is a black box system. It also is very problematic when a security issue (or backdoor) is found as your data is basically exposed

Ultimately you are right about this which is sad. I wonder if at some point there could be a zero knowledge cache for https. Maybe double encrypt it and have the client decrypt it fully.

Lemmchen@feddit.org on 16 Sep 2024 13:44 collapse

Link?

[deleted] on 16 Sep 2024 14:05 collapse

.

Quail4789@lemmy.ml on 17 Sep 2024 02:04 collapse

I mean, assuming you’re telling the truth about there being a competent group seriously attempting this, it’s still “trust us bro” to conclusively claim it can’t be achieved without providing a shred of evidence. This makes your original comment irrelevant and worthless.

[deleted] on 17 Sep 2024 03:26 collapse

.

Bitrot@lemmy.sdf.org on 15 Sep 2024 15:11 next collapse

Encrypt them before they’re ever put there. One example I can think of is in resilio sync, which has the option for sharing a folder to an encrypted peer. Other peers encrypt it before sending anything, that peer doesn’t have the decryption keys at all.

hperrin@lemmy.world on 15 Sep 2024 16:24 next collapse

Ultimately, you can’t. Even if everything you’re doing is encrypted, they have access to the RAM that’s holding your encryption keys.

notabot@lemm.ee on 15 Sep 2024 18:54 next collapse

It depends what you want to do with it. If it’s just for storing files/backups then encrypt them before uploading and make sure the key never goes anywhere near the VPS. If it’s for serving up something like a simple website, you probably care more about data integrity than exfiltration, so make sure you have the security, including selinux or equivalent, locked down, and regularly run integrity checks. If it’s for running something interactive, or where data will be generated or downloaded to the machine, you’re out of luck, there’s no even theoretical way of securing that against an adversary with that much access.

possiblylinux127@lemmy.zip on 15 Sep 2024 18:57 next collapse

You don’t really. Treat it as totally untrusted

ouch@lemmy.world on 16 Sep 2024 07:17 next collapse

Thanks for the comments. I agree on the general consensus, that once an encryption key enters the VPS, the encryption is compromised.

However, I’m thinking more in practical terms, eg. the service provider doing just casual scanning across all disks of VPS instances. Some examples could be: cloud authentication keys, torrc files, specific installed software, SSH private keys, TLS certificates.

Lemmchen@feddit.org on 16 Sep 2024 13:46 collapse

Modern CPUs have some RAM encryption features, but ultimately you’re running on hardware outside your control. Personally, I use full disk encryption (except for /boot) and unlock remotely via SSH, but that only helps against automatic scanning of the storage.

ouch@lemmy.world on 16 Sep 2024 16:37 collapse

Do you use dropbear and manually input the password to unlock the LUKS partition, or have you scripted something to automate that?

Lemmchen@feddit.org on 17 Sep 2024 10:31 collapse

Dropbear + manual input, but I guess you could do that as a single command somehow. I rarely restart this machine, so copying the PW from my PW manager is acceptable for me.

SirEDCaLot@lemmy.today on 16 Sep 2024 14:43 next collapse

The only way you can do this, is if the only service you use the provider for is storage. Encrypt the data before you send it to the provider and then they don’t know what they’re storing.

If they have to do any processing on it at all, then conceptually they need a plain text copy of it to feed into the CPU. And if they have that, there is nothing you can do to stop them from stealing it or using it.

There has been some research in this field, the concept is called homomorphic encryption. That is where you encrypt something in a way that allows a third party to manipulate the data without possessing a key. It is still very limited, and likely always will be due to the extreme difficulty of the question.

rowanthorpe@lemmy.ml on 16 Sep 2024 14:54 next collapse

If you’re only talking about Storage (data at rest) or Network (data in transit) then encrypt/decrypt offsite and never let symmetric keys (or asymmetric private keys) near the VPS, or for in-transit you could similarly setup encrypted tunnels (symmetric/private keys offsite only) where neither end of the tunnel terminates at the VPS. If you’re talking about Compute then whatever does the processing inherently needs access to decrypted data (in RAM, cache, etc) to do anything meaningful. Although there are lots of methods for delegating, compartmentalising, obfuscating, etc (like enclaves, TPM/vTPM…) the unavoidable truth is that you must trust whomever owns the base-infra ultimately processing your data. The one vaguely useful way to use “other people’s computers” trustlessly is with SMPC (secure multi-party computation) spread sufficiently widely across multiple independent (preferably competing - or even adversarial!) virtual-computation providers, with an “N-of-M keys” policy that avoids any single provider being able to attain a meaningful level of access to your data independently, or being able to view tangible portions of your data while providing functionality during SMPC. That stuff gets super-niche though.

Findmysec@infosec.pub on 16 Sep 2024 15:36 next collapse

Clevis and Tang but even that can only really do so much.

Just encrypt storage on-site

yaMatt@lemmy.world on 16 Sep 2024 16:48 next collapse

I’ve done a lot of thinking about this over the years.

Ultimately the answer is you cannot, at least with certainty. If you don’t own the host, you cannot trust anything that runs on the machine.

A few people have said similar, and that for me is the right answer here. I’ll expand on how I used to run my servers, but eventually decided it wasn’t worth the effort.

Having said that, there are some things you can do to protect yourself, although it depends on how much you care about your data Vs how much effort you want to put in.

For example, you can disguise your data on disk, by creating an encrypted file on Linux that you mount as a filesystem. Everything you care about runs from there. The ideal solution is you have an encryption key that you store somewhere trusted, that you use to decrypt the volume.

But then of course you have to insert that key each time your machine reboots, such as a kernel update.

You also have to manage and protect that key yourself, otherwise 💥 your data is gone.

Another thing to consider is, is your key in memory or on disk at any time. You need to decrypt the disk without the key ending up on the machine. I passed it over SSH and I assume the LUKS folks know what they’re doing about disguising the key in memory, but I don’t know for certain. I never looked.

My expectation was that I was doing something outside the norms of how these tools were designed to function, so expect unexpected results.

This isn’t to say you cannot trust any provider, it really depends how much you want to trust them.

oldfart@lemm.ee on 17 Sep 2024 05:37 next collapse

Syncthing has a concept pf untrusted node, which only gets to store files, not see them

ouch@lemmy.world on 17 Sep 2024 06:47 collapse

Interesting, I didn’t know about that.

docs.syncthing.net/users/untrusted.html

gian@lemmy.grys.it on 17 Sep 2024 10:37 next collapse

Only real option is to crypt them before putting them on the VPS, but at this point a VPS is pretty useless.

Wispy2891@lemmy.world on 17 Sep 2024 21:11 collapse

not a technical but you can’t just do full disk encryption and put the password manually at every single boot?

It seems very unlikely that a reputable hosting company would snoop even in that case

If we’re talking about 3 letter agencies, for the dedicated servers they’ll directly seize the disks…