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.
I actually made a mistake in my previous post by writing zone signing keys when I meant key signing keys.
Basically in DNSSEC there is a hierarchy of keys all the way from the DNSSEC root zone keys. Each DNSSEC-enabled domain has some key signing keys which have a signature signed by the parent zone’s keys stored in the parent zone as DS records similar to the way NS records are stored in the parent zone. This is done by the registrar for your domain. So e.g. the DS records for itjust.works would be stored in the works zone and the ones for works would be stored in the DNS root zone.
The domain owner can then use the key signing key to sign a regularly changing zone signing key (e.g. KSK might be valid for a year and ZSK for a month with some overlap to avoid outages). Both KSKs and ZSKs are stored in the zone itself as DNSKEY records.
The zone signing key is then used to sign each individual record in the zone. There is also a mechanism to certify that all the names in between and the records of other types do not exist but I don’t know the details of that. It is specifically designed to prevent enumeration of all existing records though.
So if you do all your zone signing on, say, your home server and only publish the zone via zone transfer on some DNS slave servers the organisation or person running your DNS slave servers will not be able to do anything other than publish it as is, publish an outdated version they received from you before (in which case you could switch out your DNSSEC keys to make that invalid) or not publish it at all (Denial of Service) but they could not publish their own records or modify the records you published.
Of course the caveat with that is that it only works if the clients actually validate the DNSSEC signatures of the zone/records but more and more do in recent years.
I don’t think I know enough about DNSSEC (and DNS in general) to understand what you have just mentioned. My apologies, I’ll get back to you once I’m comfortable with these technologies
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
I actually made a mistake in my previous post by writing zone signing keys when I meant key signing keys.
Basically in DNSSEC there is a hierarchy of keys all the way from the DNSSEC root zone keys. Each DNSSEC-enabled domain has some key signing keys which have a signature signed by the parent zone’s keys stored in the parent zone as DS records similar to the way NS records are stored in the parent zone. This is done by the registrar for your domain. So e.g. the DS records for itjust.works would be stored in the works zone and the ones for works would be stored in the DNS root zone.
The domain owner can then use the key signing key to sign a regularly changing zone signing key (e.g. KSK might be valid for a year and ZSK for a month with some overlap to avoid outages). Both KSKs and ZSKs are stored in the zone itself as DNSKEY records.
The zone signing key is then used to sign each individual record in the zone. There is also a mechanism to certify that all the names in between and the records of other types do not exist but I don’t know the details of that. It is specifically designed to prevent enumeration of all existing records though.
So if you do all your zone signing on, say, your home server and only publish the zone via zone transfer on some DNS slave servers the organisation or person running your DNS slave servers will not be able to do anything other than publish it as is, publish an outdated version they received from you before (in which case you could switch out your DNSSEC keys to make that invalid) or not publish it at all (Denial of Service) but they could not publish their own records or modify the records you published.
Of course the caveat with that is that it only works if the clients actually validate the DNSSEC signatures of the zone/records but more and more do in recent years.
I don’t think I know enough about DNSSEC (and DNS in general) to understand what you have just mentioned. My apologies, I’ll get back to you once I’m comfortable with these technologies