These are some quick n' dirty instructions so people can get up and running fast.
I wish I had known this was possible sooner.
Instructions:
Check that your VPN supports port forwarding and you have it enabled.
Grab your VPN's internal IP with ip a
Find the interface for your VPN. For me it's called tun0.
Open up /etc/nginx/nginx.conf
You can back it up, or comment everything out, or pick what's necessary. Here's what my file looks like.
worker_processes 1;
include modules.d/*.conf;
events {
worker_connections 1024;
}
http {
server {
listen [VPN INTERNAL IP]:[VPN FORWARDED PORT];
server_name localhost;
location / {
root '[ABSOLUTE PATH TO YOUR WEBSITE ROOT FOLDER]';
index index.html; # Relative to your website root.
}
}
}
Make sure your permissions are correct. For me, the 'other' group needs read permissions to the root folder, including where it's mounted.
Start nginx with systemctl start nginx
You can visit your website on your host machine in a browser at [VPN INTERNAL IP]:[VPN FORWADED PORT]. For me, using the internal IP is required to view the website on my host machine.
To view the website on other machines, you can use [VPN EXTERNAL IP]:[VPN FORWARDED PORT]. The only thing you need to change is the IP address.
I hope this works for you and you are inspired to selfhost and take back power from those who stole it from us.
Public key crypto, properly implemented, does prevent MITM attacks. TLS does do this, and that's all that matters here
It does, but modern public key crypto doesn't encrypt any client data (RSA key exchange was the only one to my knowledge). It also only verifies the certificates, and the topic was about payload data (i.e. the site you want to view), which asymmetric crypto doesn't deal with for performance reasons.
My post was not about "does TLS prevent undetected data manipulation" (it does), but rather if it's the encryption that is responsible for it (it's not unless you put AES-GCM into that umbrella term).
Client data absolutely is encrypted in TLS. You might be thinking of a few fields sent in the clear, like SNI, but generally, it's all encrypted.
Asymmetric crypto is used to encrypt a symmetric key, which is used for encrypting everything else (for the performance reasons you mentioned). As long as that key was transferred securely and uses a good mode like CBC, an attacker ain't messing with what's in there.
I think you're confusing the limitations of each building block with how they're actually implemented together in TLS. The whole suite together is what matters for this thread.