Weblog

In this release, no significant changes have been made to Hiawatha itself. The mbed TLS library has been updated to the latest release and I've changed the layout for directory indexes. I got tired of the previous one.

On july 24th, Google launched Chrome 68. This version will mark all HTTP websites as insecure. Although I prefer a HTTPS connection, I don't agree with all the attention this step receives. What I don't like is that I'm sure many people will interpret the 'insecure' sign as the website itself being insecure and will probably conclude that a HTTPS website will therefore be secure. But SSL/TLS doesn't make the website secure, only the connection to that website. A secure connection is important, but not the most important thing when it comes to website security.

To get a good perspective of the importance of HTTPS, simply look at this Wikipedia page and this CSO Online article. Tell me how many of those breaches are due to insecure website connections and how many due to other causes. If we really want a secure web, we should start focusing on vulnerabilities like SQL injection, XSS, file inclusions, weak or default passwords, etc. Such vulnerabilities are the cause of the majority of all data breaches. They are known for many, many years, but somehow developers still make the same mistakes over and over again.

In this weblog, Google explains the most common ways websites get hacked. Interesting to see that 'insecure connection' isn't one of those.

Within a few days, the General Data Protection Regulation (GDPR) will take effect. Hiawatha collects and stores the visitor's IP addresses. Since an IP address is personal data, it's possible that you must comply to the GDPR for that. One of the first things you must to is to determine the lawfulness of the processing. Recital 49 of the GDPR states that ensuring network and information security constitutes a legitimate interest, as defined in article 6 (1) lit f.

So, in normal English, you are allowed to store the IP address of a visitor for the purpose of securing your webserver. However, you still have to comply with the rest of the GDPR. That means that you should not keep IP addresses for longer that necessary (use logfile rotation), secure the logfiles well, be clear to your visitors what information your collect, for what reason and how you keep that information (privacy policy on your website) and stick to that.

The visitor, or the data subject to speak in legal terms, has the right to see what information about him/her is being processed. Of course, that person has to prove that he/she is indeed the owner/user of that IP address and also for what period of time. Otherwise, you have a data breach. That it's very hard or even practically impossible to prove that, is not your problem.

It’s easy to make plausible that the information in the system, exploit and garbage logfile is necessary for information security. It might be a bit more tricky for the information in the access and error logfile. You can use Hiawatha’s AnonymizeIP option to deal with that. The manual contains an error. It says that it also anonymizes IP's sent to the Hiawatha Monitor, but the Monitor doesn't collect IP addresses. It used to do so in an earlier version, but I forgot to remove that remark from the manual.

After reading all this, you may ask yourself: do I really need to go through all this hustle for just a personal website? No, article 2 (2) lit c clearly states that the GDPR does not apply to the processing of personal information in the course of a purely personal activity.

A new version of the Hiawatha webserver has been released. This release contains the ACME v2 script for Let's Encrypt. Read the INSTALL file carefully before using. When switching to this new script from the ACME v1 version, you can use your current account key. You need to use the 'register' command to update this key for the ACME v2 API.

The format of the Hiawatha access logfile has been changed a bit. The Referer and User-Agent HTTP header now have a fixed place in the logfile. The user id of the HTTP authentication has been removed.

For all changes, see the ChangeLog.

Update:

Version 10.8.1 has been released. This release contains mbed TLS 2.8.0 (was released at the same moment as Hiawatha v10.8 ) and some fixes for the ACME v2 script.

Some time ago, Let's Encrypt announced that they will be supporting ACME v2 on February 27, 2018. I'm already busy implementing ACME v2 support in Hiawatha's Let's Encrypt client. It's almost finished. There are just some small issues to fix, but those might be a server-side bug as well.

Another new Let's Encrypt feature that's coming in February 2018, is support for wildcard certificates. The issue is that they can only be obtained via a DNS challenge instead of via the HTTP challenge I'm currently using. Using a DNS API is not an option, because not every DNS provider offers an API for DNS changes and there is also no single standard for such API. At the moment, I'm discussing my idea about how to obtain a wildcard certificate via an HTTP challenge with Let's Encrypt and the ACME Working Group at IETF. Hopefully they accept my idea.

Anyone who wants the try the new version of Hiawatha's new Let's Encrypt client, you can download it here.