Server speed

An important feature of a server is the speed of its internet connection, or more precisely, its latency and bandwidth. How can we measure these quantities if all we have is command line access?

Regarding latency, look at my last post. Here's an example from with the fastest mirror:

± netselect -vv
Running netselect to choose 1 out of 1 address.
............ 2 ms   6 hops  100% ok (10/10) [    3]

If you want a closer look at the 6 hops, use mtr-tiny.

Concerning bandwidth, use speedtest-cli:

sudo wajig install speedtest-cli

Here's an example from

± speedtest
Retrieving configuration...
Testing from netcup GmbH (
Retrieving server list...
Selecting best server based on ping...
Hosted by IT Ohlendorf (Salzgitter) [111.93 km]: 11.215 ms
Testing download speed.................................................
Download: 427.58 Mbit/s
Testing upload speed...................................................
Upload: 393.16 Mbit/s

Hm. A ping of 2 ms and a symmetric down- and upload of 0.4 GB/s for a handful of € per month? Why can't I have that at home?

HTTPS mirrors

And while we're at it, let's also configure HTTPS mirrors for our package updates. That may seem superfluous at the first glance, as these packages are public content and are signed with the private GPG keys of the developers, certifying their authenticity. However, the signatures are only one part of the story, and the encrypted transfer is the other. In fact, updates installed via a plain-text HTTP connection can be intercepted by GPG replay attacks. A comprehensive analysis of this scenario was done a decade ago at the University of Arizona. The following brief summary is due to Joe Damato:

“Even with GPG signatures on both the packages and the repositories, repositories are still vulnerable to replay attacks; you should access your repositories over HTTPS if at all possible. The short explanation of one attack is that a malicious attacker can snapshot repository metadata and the associated GPG signature at a particular time and replay that metadata and signature to a client which requests it, preventing the client from seeing updated packages. Since the metadata is not touched, the GPG signature will be valid. The attacker can then use an exploit against a known bug in the software that was not updated to attack the machine.”

The distributions I'm currently using and am familiar with (Archlinux and Debian) do not use HTTPS mirrors by default, but can be coaxed into doing so.

That's particularly easy for Archlinux after installing reflector, a python script that allows to filter mirrors by various criteria such as their geographical location, up-to-dateness, download rate, and, last but not least, connection protocol. The following one-liner overwrites /etc/pacman.d/mirrorlist with the current top-ten of all HTTPS mirrors in terms of up-to-dateness, overall score and speed:

reflector --verbose --protocol https --latest 100 --score 50 --fastest 10 --sort score --save /etc/pacman.d/mirrorlist

This command can be run manually, or automatically by either using a pacman hook to trigger it in the event of mirrorlist updates, or by a timed systemd service. Reflector is thus an as flexible as convenient tool for selecting the optimum mirrors.

I expected that Debian would offer something equivalent, but to my considerable surprise and disappointment, there's nothing coming even close. The netselect derivative netselect-apt is only capable of finding the ten fastest mirrors for the relevant release of Debian (i.e, stable, testing, or sid). But how do I know if these mirror support HTTPS? To the best of my knowledge, the only way short of trying them one-by-one is the python script available here (or one of its forks).

Armed with this script (I'm using the multithreaded variant), I usually just create a list with all mirrors, which I then pipe through netselect to find the fastest one:

± ./ --generic --no-err | awk '{print $1}' | grep https | tr '\n' ' ' | xargs netselect -vv

Oh, and one should not forget to install 'apt-transport-https' to allow apt to use HTTPS mirrors. Only true Debilians will find this situation tolerable.

Let's encrypt

Ever since I've set up the new server for this blog, I've wanted to make the switch from plain HTTP to TLS-encrypted HTTPS (if you think HTTPS is for online shops and banks only, think again).

This transition turned out to be much easier than I thought. Hiawatha, our web server of choice, comes with a script that takes care of registering the site at Let's Encrypt and requesting certificates for the associated domain(s). Chris Wadge, the maintainer of Hiawatha for Debian, provided an excellent tutorial guiding through the few steps necessary to configure Hiawatha for serving HTTPS content.

Since I had to configure vhosts for the certificates anyway, I took the opportunity to set up some proper subdomains. For example, this blog can now be reached at

After a bit of tweaking (setting HSTS to one year), the security rating of our site is flawless: