How can I prevent my VPS provider from accessing my decrypted VPN data?

Here's a crazy idea. Create a large empty file on your VPS. Call it backingfile.lol. Then remotely mount the directory containing backingfile.lol using sshfs on your local machine, so that you can access backingfile.lol as if it were a local file. Then create a loopback device on the local machine using backingfile.lol as the backing file, and create a luks device on top of the loopback device. Format the luks device with the filesystem of your choice, mount the filesystem, and rsync your secret files with it. Tear down everything except backingfile.lol on the VPS when not in use, and your files will persist inside it.

If my understand about all this is correct, your adversary could have physical access, root access, and Intel's own ME signing keys, but will see only encrypted data at rest on the VPS, because your keys never leave the local machine, affording him no recourse short of cracking AES.

As others have pointed out this is possible using confidential computing / secure enclaves. It's actually a pretty great application if I understand what you are doing correctly because you are running a relatively simple and self contained process in the enclave. Don't use SGX which has been pwned so many times it is a meme: https://en.wikipedia.org/wiki/Software_Guard_Extensions#List.... AWS has something that looks ok for VPS. AMD SEV-SNP is pretty nice. I know you can get SEV-SNP working on hosted dedicated servers not sure about VPS providers.

If you want to do a crazy science project you could look at the Marlin network which apparently lets you execute code in enclaves on random people's computers. Probably the throughput these random people would not be practical to run your VPN.

This does not really answer your question but there just isn't a good answer given most VPS providers can live-snapshot and live-migrate nodes despite not making that a service. If something is in memory it's under their control regardless of any magical memory encryption implementation providers claim to use.

Use something you control vs. something managed. In other words do not use a VPS and instead send small throw-away servers to low-end colocation sites. Seal the servers by filling them with black epoxy and pre-configure them to be low-power and thus low-heat and "plug-and-play" so that you can just ship them to the colo, they rack mount and it just turns on, gets DHCP information and "just works". Disable all logging and run everything in ram when it boots. Physically remove all solder from all ports except the one ethernet port you wish to DHCP from and sever the board traces. Use a custom BIOS that removes all JTAG debugging and out of band management. Have a DNS query in cron that makes an obscure request to an "all clear" zone. If that DNS entry vanishes the box assumes duress and zeros out ram and storage. When it fails tell them to trash it. Do not send them a replacement as they may have destroyed it trying to get your data. Just let that account fade away. Bonus if you can put the box on the internet without any accounts or business relationships.

None of this is my idea or a new idea. This is not too different than how Akamai CDN devices worked in shared datacenters minus the black epoxy. The black epoxy was used in an early satellite TV decoding box in the 1980's that people eventually learned to drill in the right spots to get free premium channels and porn before people obtained media from the internet. Many decoders were destroyed in this learning process. VideoCipher II has quite a history. Spies and prisoners hide servers in crawl spaces and manage to get them connected to the internet all the time.

you forget, they can just capture all data from the switch port.

I did not forget. The data is encrypted and keys are pinned on each side ahead of time. If the concern is hiding the source IP then one could route through multiple L4 vips using HAProxy on nodes in other countries. With time and money they may be able to penetrate each layer but one has to be worth the time and money.

> If something is in memory it's under their control regardless of any magical memory encryption implementation providers claim to use.

That's not true. For example, to live-migrate Confidential VMs running on AMD SEV-SNP or Intel TDX, there is an extra step of negotiating encryption keys for live migration so that the hypervisor never sees plaintext memory pages of the guest VM. A few relevant docs:

* https://lpc.events/event/11/contributions/958/attachments/76...

* https://lpc.events/event/17/contributions/1532/attachments/1...

* https://lpc.events/event/11/contributions/960/attachments/83...

I'm not aware of any Confidential Computing platform where it is possible to snapshot/cold migrate VMs at all.

Assuming one trusts this model and there are no implementation bugs or undocumented lawful intercept API's one would be stuck with Google Cloud or Azure. I assume AWS probably also has this. Who else?

Given it's used by the big providers one has to assume there are lawful intercept API's or some other mechanism to abide by lawful orders to monitor traffic given MitM will not work. eBPF perhaps to grab keys or intercept the HSM if not API's.

> My main question is: Is there any method or configuration that can ensure that even on my self-hosted VPS, the provider cannot access my data?

Short answer: No, you cannot.

Long answer: It depends on the resources they plan to allocate on the task. This article provides an excellent deep dive into the topic, based on an fairly recent incident involving an XMPP server in Germany: https://www.devever.net/~hl/xmpp-incident

Unless you trust secure enclaves (like SGX) and run your code there, I don't see a way.

Is there a reason for not running your VPN from home?

In the end you will develop something like TOR.

Https is transit level encryption. Application level encryption is encrypting the data inside the https connection, Eg if your post body is encrypted.

And never decrypting the data on the server is one way to handle your question.

Look up confidential computing, some providers offer this feature

What’s your goal and what’s your threat model?

i.e. it’s hard to answer the question if you can’t state kind of data/metadata you are worried about leaking.

DNS lookups are probably the hardest to conceal.