4 ms·

> When you self-host, the government has to come to you for your data. Right, and your example of a literal server in a basement supports that, but if you are

by lbotos 5y ago

> When you self-host, the government has to come to you for your data. Right, and your example of a literal server in a basement supports that, but if you are colocating or using a VPS they will almost definitely go to your provider first and probably won't even tell you.

cube00 5y ago
If you encrypt the disk is a VPS provider going bother going to effort of trying to hook into the running machine via their hypervisor in a way that won't be evident to the owner of the server? I'm not saying they can't I just don't see that they would spend their time doing this when they can send to the request to the server's owner and then it's no longer their problem to deal with.
- the_rectifier 5y ago
  Dumping VM memory contents is pretty trivial.
  - deleted 5y ago
    [deleted]
  - 10000truths 5y ago
    AMD's SEV and Intel's SGX should protect from this. Of course, you still have to take the VPS provider's word that they've enabled them on their CPUs.
    - closeparen 5y ago
      That is for applications specifically written to compute on the secure element, no?
      - gruez 5y ago
        The parent poster probably got his terminology confused. AFAIK SGX runs on the secure element, SEV is for isolating the VM from the host.
    - gruez 5y ago
      ...which is approximately zero VPS providers. I haven't seen them advertised outside of specialty azure/aws instance types.
    - d110af5ccf 5y ago
      > you still have to take the VPS provider's word that they've enabled them No, you don't. Both of those implementations provide hardware attestation via vendor keys securely embedded in the CPU. I have no idea if any providers currently make such features available though.
- 404mm 5y ago
  Unless you’re in an environment where you literally have to type or provide the decrypting key on each start, you are dealing with a situation where your provider has both the encrypted data and the encryption key.
  - throw0101a 5y ago
    > Unless you in an environment where you literally have to type or provide the decrypting key on each start The OS may boot up, but one could have the data on a separate volume. Services won't start until that volume is mounted, which could be manual-only. Either LUKS-on-any-FS or encrypted ZFS would work. With encrypted (Open)ZFS you can actually send encrypted bits remotely: the destination does not need the key to save the bit stream to disk, so you can have a secure cold storage copy of your data. > There's an even more compelling reason to choose OpenZFS native encryption, though—something called "raw send." ZFS replication is ridiculously fast and efficient—frequently several orders of magnitude faster than filesystem-neutral tools like rsync—and raw send makes it possible not only to replicate encrypted datasets and zvols, but to do so without exposing the key to the remote system. > This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. With raw send, your data is replicated without ever being decrypted—and without the backup target ever being able to decrypt it at all. This means you can replicate your offsite backups to a friend's house or at a commercial service like rsync.net or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. * https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/ https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...
    - pc86 5y ago
      Nobody is arguing that it's not possible. We're just saying it's a huge hassle and that even being willing to go through the hassle on every boot is itself a red flag.
      - pessimizer 5y ago
        It's not a huge hassle, it's a mild hassle. I'm no ZFS expert, but LUKS is trivial.
johnklos 5y ago
Nope. If you colocate hardware which you own (which is what colocation means), then they can't just go get your hardware. Even if they break the law and nab your hardware, you'll know because it's down. With VPSes, they can get your data and you might never know. It's an extremely important distinction.
- snowwrestler 5y ago
  To clarify this, the government has to go through certain procedures to seize your private property. If you own a hardware server, it is your property, even if it is sitting in someone else’s data center.
  - takenpilot 5y ago
    Supposedly they have to do that for safety deposit boxes too, but as recent events have shown in LA, that doesn't stop them from seizing everything including those boxes and then opening them up to take inventory. A judge objects, but it's too late. Now people are having to prove that they own whatever was in those boxes to get back their stuff back, and if they can't -- everything is gone.

by lbotos 5y ago

cube00 5y ago

If you encrypt the disk is a VPS provider going bother going to effort of trying to hook into the running machine via their hypervisor in a way that won't be evident to the owner of the server? I'm not saying they can't I just don't see that they would spend their time doing this when they can send to the request to the server's owner and then it's no longer their problem to deal with.

the_rectifier 5y ago
Dumping VM memory contents is pretty trivial.
- deleted 5y ago
  [deleted]
- 10000truths 5y ago
  AMD's SEV and Intel's SGX should protect from this. Of course, you still have to take the VPS provider's word that they've enabled them on their CPUs.
  - closeparen 5y ago
    That is for applications specifically written to compute on the secure element, no?
    - gruez 5y ago
      The parent poster probably got his terminology confused. AFAIK SGX runs on the secure element, SEV is for isolating the VM from the host.
  - gruez 5y ago
    ...which is approximately zero VPS providers. I haven't seen them advertised outside of specialty azure/aws instance types.
  - d110af5ccf 5y ago
    > you still have to take the VPS provider's word that they've enabled them No, you don't. Both of those implementations provide hardware attestation via vendor keys securely embedded in the CPU. I have no idea if any providers currently make such features available though.
404mm 5y ago
Unless you’re in an environment where you literally have to type or provide the decrypting key on each start, you are dealing with a situation where your provider has both the encrypted data and the encryption key.
- throw0101a 5y ago
  > Unless you in an environment where you literally have to type or provide the decrypting key on each start The OS may boot up, but one could have the data on a separate volume. Services won't start until that volume is mounted, which could be manual-only. Either LUKS-on-any-FS or encrypted ZFS would work. With encrypted (Open)ZFS you can actually send encrypted bits remotely: the destination does not need the key to save the bit stream to disk, so you can have a secure cold storage copy of your data. > There's an even more compelling reason to choose OpenZFS native encryption, though—something called "raw send." ZFS replication is ridiculously fast and efficient—frequently several orders of magnitude faster than filesystem-neutral tools like rsync—and raw send makes it possible not only to replicate encrypted datasets and zvols, but to do so without exposing the key to the remote system. > This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. With raw send, your data is replicated without ever being decrypted—and without the backup target ever being able to decrypt it at all. This means you can replicate your offsite backups to a friend's house or at a commercial service like rsync.net or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. * https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/ https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...
  - pc86 5y ago
    Nobody is arguing that it's not possible. We're just saying it's a huge hassle and that even being willing to go through the hassle on every boot is itself a red flag.
    - pessimizer 5y ago
      It's not a huge hassle, it's a mild hassle. I'm no ZFS expert, but LUKS is trivial.

johnklos 5y ago

Nope. If you colocate hardware which you own (which is what colocation means), then they can't just go get your hardware. Even if they break the law and nab your hardware, you'll know because it's down. With VPSes, they can get your data and you might never know. It's an extremely important distinction.

snowwrestler 5y ago
To clarify this, the government has to go through certain procedures to seize your private property. If you own a hardware server, it is your property, even if it is sitting in someone else’s data center.
- takenpilot 5y ago
  Supposedly they have to do that for safety deposit boxes too, but as recent events have shown in LA, that doesn't stop them from seizing everything including those boxes and then opening them up to take inventory. A judge objects, but it's too late. Now people are having to prove that they own whatever was in those boxes to get back their stuff back, and if they can't -- everything is gone.