I have made a few technical changes to the blog and the website over the last few days. The most visible ones are that the access to the website is encrypted by default now, i.e. you will see in the address bar that the URL starts with https and that the lock symbol next to it is activated or shown as closed. That means that all the data exchanged between the web server on which the blog is hosted and your web browser is both encrypted and cryptographically signed. Those two properties ensure that nobody, not even people who have access to the data path between the devices, can easily read the data, nor tamper with them, i.e. change them on their way from the server to you.

Why is this relevant for a public website at all? Is not all the content public anyway?

The content is indeed publicly accessible, that is true in this case. The main benefit for the user is that they can be sure that the content was not altered (e.g. no malicious code was injected) on the internet, or in any unsecured local network that your device is connected to. That insecure local network could, for example, be an open WiFi in a coffee shop, supermarket, public library, the internet service on public transport, or at the airport. The list of free public internet access points has increased dramatically over the last years.

For websites that deal with private data provided by the user, such as credit card details or other personal information, an encrypted connection is, of course, essential to protect that data.

Technical Implementation

I will not go into detail here, because there are many well-written instructions and howtos online available. However, I want to stress that it is relatively straightforward for someone with technical expertise to enable encrypted HTTPS access for a website. The most complicated step has historically been to get a certificate for that domain or server that is signed by an official Certificate Authority. Anyone can in principle sign their own server certificates, but the web browsers of any visitors to the site would not trust them (for good reasons). Thanks to initiatives such as Let’s Encrypt and others who provide free official certificates, whose certification chains are trusted by the vast majority of modern web browsers, that step has become significantly easier.

In the case of Let’s Encrypt, one needs to perform roughly the following steps:

• Install a certificate program or bot that supports the Automatic Certificate Management Environment (ACME) challenge-response protocol

• Add a section to its configuration file for the relevant website or domain

• Configure a well-known area on the web server for the ACME challenge-response communication

• Request a certificate for the website

• Install that certificate in the web server and enable HTTPS

• Ensure that the certificate program runs periodically every day or so to renew the certificate before it expires

It seems like many steps, but it is a reasonably straightforward way to a secured website. I leave any further configuration changes as an exercise for the reader. ;-)