I run a self-hosted server at home on which I have run a bunch of personal stuff (like nextcloud etc.). To prevent pointing DNS servers at my home router, I run a reverse proxy on a VPS that I rent (from Scaleway FWIW).

Today I was trying to figure to what extent that exposes my data to my VPS provider and whether I can do something about it. Disclaimer: this is just a hobby exercise. I’m not paranoid, I just want to learn for my own self how to improve security of my setup.

My reverse proxy terminates the SSL connection and then proxies the connection over a wireguard connection to my home server. This means that (a) data is decrypted in the RAM of the VPS and (b) the certificates live unencrypted in the storage of the VPS. This means that the VPS provider, if they want to, can read all the traffic unencrypted to and from my home server.

I was thinking that I can solve both problems by using Nginx’s SSL pass-through feature. This would allow me to not terminate SSL on the VPS solving (a) and to move the certificates to my home server solving (b).

But just as I was playing around with it, I realised that SSL pass-through would not solve the problem of trying to protect my data from the VPS provider. As long as my DNS records point at the VPS provider’s servers, the VPS provider can always get their own certificates for my domains and do a MitM attack. Therefore, I might as well keep the certificates on the VPS since I still have to trust them not to make their own behind my back.

In the end I concluded that as long as I use a VPS provider to route my traffic to my home server, there is no fool-proof way to secure my data from them. Intuitively it makes sense, the data crosses their hardware physically and thus they will have access to it. The only way to stop it would be to update the DNS records to point directly at my home server which I don’t want to do.

Is this correct thinking or is there some way to prevent the VPS provider from seeing my data?

Again, I’m trying to solve this problem as a hobby exercise. The most sensitive data that I have is stored encrypted at the filesystem level and I only decrypt it locally on my own machine to work on it. Therefore, the actually sensitive data that would be cost me a lot if compromised is never available unencrypted on the VPS. Due to the overhead of this encryption and other complications, I don’t do this for all my files.

You are viewing a single thread.
View all comments
5 points

Best option is to directly NAT traffic from VPS to your home server, either directly to your IP or set up a wireguard peer and send traffic via wireguard to your local and do the SSL/TLS termination on your local.

You are best exposing just 443 port on the VPS and moving that traffic over wireguard. Server will have your local public key on the server, and you could implement a wireguard key rotation to change them frequently.

Traffic sent back will be encrypted with the certificate, and even if they get the wireguard server key, you can rotate it, but still they will see encrypted packets.

It depends what kind of things you’re doing on your local. If it is just a website thing, then reverse proxy is fine. Anything other than that, NAT would be cleanest one.

LUKS on the disks would encrypt it the data on the block storage level, and, in theory, they should not have a way of reding block storage files directly. But since it is a VPS they can, technically, gather data from host memory.

Next step might be going down a dedi server route, Luks encryption on disks. Only thing thats needed there would be sufficient network pipe.

permalink
report
reply
1 point

Hi, could you explain the concept of DNAT, SSL termination and how using DNAT lets us terminate TLS at our home? I’m a bit confused

permalink
report
parent
reply
8 points

No problem. I’ll just go with a oversimplification.

The idea is that you just take whatever traffic hits port 443 and use iptables rules to route the traffic elsewhere, or in this case

Client --> [port 443] --> [iptables] --> [ port 443 home server]

So, it’s basically just traffic forwarding from the VPS directly to your home server, being directly to your ISP IP address, or via wireguard IP address.

So all the traffic you are sending back from the VPS is in its original state, and the actual processing happens on your local/home server.

On the home server you have a Web Server of your choice listening on port 443 with, loaded with your SSL certificates. So, request is made to the VPS IP address, iptables just forward the packets to your home server, and there is where the SSL/TLS termination happens. The client negotiates the TLS connection directly with your home server, and web server on your home server then sends the request where you tell it to ( reverse proxy to a docker container, or it serves the content directly).

With this, you basically turn the VPS into a passtrough for traffic.

Here’s a quick test I did… the two servers are connected with Wireguard mesh.

On the VPS you need have net.ipv4.ip_forward=1 .

net.ipv4.ip_forward=1

Your iptables rules should be. Obviously on the home server you can run the webserver on any port you like, doesn’t have to be 443. But let’s keep it 443 for the sake of argument.

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination HOME_SERVER_IP:443
iptables -t nat -A POSTROUTING -j MASQUERADE

If you want to drop the rules:

iptables -t nat -F
permalink
report
parent
reply
1 point

Thank you for the answer. I was hoping that I could implement a DNAT on the VPS box and then have HAProxy on my router do the SSL termination and serve requests. Just to be sure, that would be possible, yes? I understood how the system works, thanks a bunch!

permalink
report
parent
reply

Selfhosted

!selfhosted@lemmy.world

Create post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

Community stats

  • 5K

    Monthly active users

  • 3.5K

    Posts

  • 77K

    Comments