3 ms·
>It's odd that NordVPN, VikingVPN and Torguard all got their private keys leaked here. Good reminder to set up FDE and not give your host logins for your serve
by FDSGSG 7y ago
>It's odd that NordVPN, VikingVPN and Torguard all got their private keys leaked here.
Good reminder to set up FDE and not give your host logins for your servers. Unexpected reboots are rare enough that they're worth switching hosts over.
- tmikaeld 7y agoFor dedicated servers this would work, especially for VPN where data-loss is "acceptable". But if it where based on containers like LXC or OpenVZ, then the host can force root access via a command without even changing the root password of the container.
- pm7 7y agoI doubt serious VPN provider are using LXC/OpenVZ containers. They don't even work with OpenVPN without special setup from provider, I don't know how about other protocols.
- tmikaeld 7y agoBoth LXC and OpenVZ can run VPN services with just setting a couple of flags, I've done it on both.
- pm7 7y agoI know, but these flags have to be set by provider of container, not user (provider of VPN). And they might require changes in kernel.
- ju-st 7y agoNordVPN _was_ (and certainly still is) using LXC containers. Look at the document linked in the Techcrunch article.
- FDSGSG 7y ago>For dedicated servers this would work, especially for VPN where data-loss is "acceptable". FWIW there's no need for data loss when you ditch the server, just download the encrypted data and decrypt using a clean environment elsewhere. >But if it where based on containers like LXC or OpenVZ, then the host can force root access via a command without even changing the root password of the container. You should never do this, unless you truly don't give a shit about whatever you have on the server.
- tmikaeld 7y agoI mean that encryption puts the entire data-store at risk, I've seen it happen more than twice due to RAM being faulty (In one incident it was using ECC RAM) and a power-failure. Even the backups where corrupt due to being backed up in encrypted images. When encrypted volumes and images are corrupted by RAM or power-failure, they are locked forever. Of course one should never force root access, I'm saying that you can't keep out the hosting from access the server in that case.
- pm7 7y ago> Even the backups where corrupt due to being backed up in encrypted images. When encrypted volumes and images are corrupted by RAM or power-failure, they are locked forever. That sounds more like issue with backup procedure (and testing of backups), even if it was amplified by encryption. > Of course one should never force root access, I'm saying that you can't keep out the hosting from access the server in that case. LXC and especially OpenVZ containers seems to be replaced by KVM in hosting/cloud. Of course, it's still possible to attack VM as host has control over VM's memory. Even dedicated servers are potentially vulnerable to attacks like cold boot. > In one incident it was using ECC RAM Did it at least warn about issues or was it ignored? > I mean that encryption puts the entire data-store at risk, I've seen it happen more than twice due to RAM being faulty (In one incident it was using ECC RAM) and a power-failure. How can this cause data loss? Header containing encryption key should not change during normal work. Did it just corrupt writes?
- FDSGSG 7y agoYeah this sounds so weird. Data loss due to bad RAM will be extremely similar with or without encryption, it's not going to corrupt the header of the disk. The catastrophic data loss you describe almost certainly resulted from you doing something horribly wrong, and not encryption.