I'm getting MITM'd by my ISP when trying to view this site and some others. It manifests as an SSL certificate error, and if you ignore the warning, it shows that stupid mcafee thing. Does anyone know how to not get MITM'd by my ISP? I'm already using DNS servers 1.1.1.1, 1.0.0.1.
Looked into it a bit more, I don't think DNS is the issue. The request goes to the correct IP address, and then my ISP does the MITM attack based on the IP address. So, instead of getting justine.lol's SSL certificate, I get a certificate instead for *.safezone.mcafee.com. Firefox correctly flags this as a bad SSL cert, and I don't want to accept the bad cert, so I basically just don't have internet access to these websites using my ISP.
Author here. I use MbedTLS to serve justine.lol using Let's Encrypt and TLS v2 with a permissive policy regarding older (but not yet obsolete) crypto formats and protocol versions (because I like supporting old browsers and old operating systems). If there's a weakness in the way I'm doing it, then I want to know about it. It might be possible that your client accepts older weaker SSL varieties and the MiTM is using that somehow as an attack vector. If so, you can try changing your browser settings. It might also be time for me to consider trading away some compatibility by forcing clients to use stronger security. Let me know what you learn! My email is in the blog post.
It's not your fault, it's my shitty ISP. I was able to access the article after discovering a setting to disable it in my modem/router. Thank you for sharing your work!
I use a SOCKS5 proxy on ramnode.com (from when they had OpenVZ for $15/year, which I think hasn't been available as a new plan for a bit now and I think will be increased or removed as an option at the next biling period; it looks like the lowest cost option is now $42/year). I change SSH to only allow certificate login (and only the particular algorithms I want to use, and listen on ports 80 and 443 to work around some wifi limitations), enable auto OS updates, and stop everything else from listening on the network to keep the chance of something being exploitable to the minimum and it just works. I sparately pass local port 853 to Google's DNS over TLS via the SSH connection (I use ssh -o VisualHostKeys=yes -NMD localhost:2000 -L localhost:853:8.8.8.8:853 and set ALL_PROXY=socks5://127.0.0.1:2000; I've learned that the visual host keys do not help at all with the thing it is supposed to do but I find it an artistic way of saying the connection is up).
I'm not sure how common it is for hosting providers to allow that kind of traffic (I think many do not) and I'm not sure how their privacy policy for that kind of use compares to others but at least they don't try to MITM traffic. Occasionally I get sites that simply block the address range (like Wikipedia for editing last I checked, although viewing works fine) and limitations or oddities will likely be worse at first (Google really wanted to redirect me to their Hong Kong search page for a while when I first stared doing this) but it is rare that I have an issue now. I'm also on CenturyLink (which I chose as still better than Comcast since you can at least use your own device) and I recommend this method (also helpful when using wifi). Another potential downside is that you don't get the local CDN caches, which I'd guess most impacts the online movie services (I don't use them and only have a 12mbps download anyway so it would hardly be the bottleneck). I think routing DNS through SOCKS helps get the closest CDN locations to the proxy (at least using encrypted DNS is a must since CenturyLink messes with that too if you try to use another DNS provider unencrypted).
