If like me you've got something on your network monitoring DNS requests, such as Pi Hole or AdGuard Home, and you have a computer or two or three running Linux, you've probably seen many requests like the above. Odds are they hit your top domains, especially if you have multiple machines running the same distro.
I fiddle with a few different distros but I tend to stick to Ubuntu for my main one. I have three machines on my network running Ubuntu. As you can see, they frequently connect to the domain connectivity-check.ubuntu.com.
Every single OS on every single device – whether it's a computer, smartphone, or IoT device – pretty much does the same thing. For example Windows uses the rather more cryptic domain msftncsi.com, standard Android pings connectivitycheck.gstatic.com, and even my phone running Graphene OS – a fork of Android focused heavily on security and privacy – checks in now and then with connectivitycheck.grapheneos.network.
The purpose of these domains is quite self-explanatory: it's simply a way for the device to check if it's connected to the internet. If not, it'll show an error letting you know there's a connection problem, or if it detects a captive portal (e.g. a login page for hotel WiFi) it'll redirect you to that.
It's often the case that one server or VPS can easily run multiple sites, each with their own domain names. Even though it sacrifices some security, SNI is pretty much what we've collectively chosen to use to make this possible while still using TLS (HTTPS, SSL).
This is largely necessary because it's the norm for multiple sites to share the same IP address. When running multiple sites from a VPS, it's possible for this to mean anyone visiting one of your sites can see the TLS certificates for the other domains you serve up, and regardless, it's very easy to simply perform a reverse lookup on an IP address to look at all the domains pointing to it as DNS records are public.
And this may just be me, but it feels a bit “hacky.” Whenever someone visits your site, the browser can work out which is the correct vhost to talk to thanks to SNI, but having a bunch of rejected and invalid TLS certs coming from that same IP is just not a “clean” setup.
From the cheapest managed website hosting plan to the most high end rented server, if you plan to serve content over the internet, HTTPS is no longer optional.
As a result, pretty much every host out there will chuck in a free SSL certificate. Quick pedantic sidenote: although they're still very commonly referred to as SSL certificates, even by experts, no one actually uses the SSL protocol anymore because it's no longer secure. Today what we use is TLS.
Specifically, TLS 1.3 is the most recent version but lacks support in older clients, while TLS 1.2 is outdated and less secure but far more widely supported compared to 1.3, and by using a small list of good, secure ciphers you can avoid the exploits that have plagued TLS 1.2. Ideally, using only the latest version is best. In fact if you happen to be reading this a few years after publication you'll probably be fine dropping TLS 1.2.
But I'll stick to the here and now: 2021. By default, most web servers enable insecure protocols such as TLS 1 and TLS 1.1. These should not be used at all. They're inherently insecure.
In this post I will assume you either have a server you're setting Nginx up on, or already have an Nginx server up and running which you wish to upgrade the security of. I won't go over other important steps in securing a server such as firewall settings, SSH keys, auto updates and the like although I will cover these in a future article and in this one I will give you a few tips that can help prevent exploits just by changing your Nginx config.
An announcement published today on the official Signal blog is encouraging users to setup an open source Signal TLS proxy in order to help people in Iran, and possibly other countries in the not too distant future as the app has suddenly exploded in popularity as of late, continue to be able to access and use the end-to-end encrypted messaging app even as their governments block access to it. The Signal blog post puts the focus on Iran as they just recently blocked Signal, but I would not at all be surprised if nations such as China and Russia followed in their footsteps very soon. These proxies could end up being useful to millions worldwide.
If you have have set up a VPS before, and you have a spare domain lying around or an active one you don't mind creating a subdomain for, you can easily help out this decentralised community effort by running Signal's TLS proxy.
The instructions on Signal's site are very easy to follow if you are familiar with all this stuff already. So if you know how to spin up a VPS, point a domain at it, and install an automated Docker image just read the Signal post.
This post is a mini-guide for noobs with more specific instructions on each step. If you know your way around a computer but are a bit fuzzy on setting up a VPS, you are the target audience for this post.
Important note: Eventually the Iranian government, and other oppressive governments who may block Signal in the future, are likely to block the domain of your proxy. If this is a concern to you just pick up a cheap domain exclusively for the proxy. The IP of the server you use would be blocked too but this shouldn't matter as we will be using a separate VPS.
If you want your existing domain to stay accessible in countries with oppressive regimes, it is highly advised to set this up on a a new or unused domain.
Thankfully, this is a very lightweight application that will run on even a very cheap VPS. And a domain can be purchased for a couple quid a year depending on the TLD.