Normally I blog about SQL Server, but I have found this (and one more coming) answers to questions that I could not find on the internet. So I had to share!
As many folks who start dabbling in home VPN setups realize or had known prior (I’m a database guy, not a network admin!), you need a DDNS provider. Your home IP will probably change, so if you wanted to connect to your home IP, it may work for a little while, but it may change unexpectedly. Having it update every few minutes with a provider so they can give you a static name to use that maps automatically to your new IP is the solution to keep it working consistently.
There are many benefits to running a home VPN and using a DDNS service, but the benefit I was after is blocking all adds on my phone. Not just blocking them from being seen, but blocking them from even starting to be downloaded. I run a PiHole at home that blocks ads at the DNS level and is my DNS server. So putting my phone on my home network at all times lets me save data AND block ads EVERYWHERE. If that wasn’t great enough, you can access home files and will have a secure connection to use if you are on a WiFi connection you may not trust.
After dabbling and following some fantastic tutorials as seen by Lauren Orsini on ReadWrite.com and Sam Hobbs on Samhobbs.co.uk I made a lot of progress and got to where I needed an application (DDClient) to update my IP to my DDNS provider and I ran into a problem. Sure it was working, my IP was being updated. But how could I be sure that I was connecting over SSL? Was I transmitting my username and password over plain text across the internet? The answer is, yes.
Here’s the format for a typical DDClient config file:
daemon=60
syslog=yes
mail=root
mail-failure=root
pid=/var/run/ddclient.pid .
ssl=yes
use=web, web=myip.dnsdynamic.org
server=www.dnsdynamic.org
login=USERNAME
password=PASSWORD
server=www.dnsdynamic.org, \
protocol=dyndns2 \
YOUR DOMAIN GOES HERE
Looks fine enough right? Well, it’s not.
If you run this:
sudo ddclient -verbose -debug -noquiet -query
You will quickly see you are connecting over HTTP, not SSL. Even though we have the value ssl=yes, it SHOULD be forcing HTTPS, but we can clearly see our connections are in plain text floating around the internet.
use=web, web=loopia address is IPADDRESSISHERE
CONNECT: myip.dnsdynamic.org
CONNECTED: using HTTP
SENDING: GET / HTTP/1.0
SENDING: Host: myip.dnsdynamic.org
SENDING: User-Agent: ddclient/3.8.2
SENDING: Connection: close
A lot of times I solve problems when I come back to them with a fresh brain and a few cups of coffee. So after a reminder about my problem, I was able to figure out that if I add a simple eight more characters, we would no longer fly through internet tubes seen, but we would be secured.
I changed the line use=web, web=myip.dnsdynamic.org to use=web, web=https://myip.dnsdynamic.org and here’s the new output from the query:
use=web, web=loopia address is IPADDRESSISHERE
CONNECT: myip.dnsdynamic.org
The verification of cert '/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA/CN=www.dnsdynamic.org'
failed against the host 'myip.dnsdynamic.org' with the default verification scheme.
THIS MIGHT BE A MAN-IN-THE-MIDDLE ATTACK !!!!
To stop this warning you might need to set SSL_verifycn_name to
the name of the host you expect in the certificate.
CONNECTED: using SSL
SENDING: GET / HTTP/1.0
SENDING: Host: myip.dnsdynamic.org
SENDING: User-Agent: ddclient/3.8.2
SENDING: Connection: close
Success! I’m not too concerned about the cert issue, if you look, it’s the same subdomain listed. So the query above shows you how you can verify you are connecting over SSL and the config file adjustment with HTTPS resolves your SSL connection.