Weblog

Everything that has a beginning, has an ending. In 2002, the Hiawatha webserver was born. It started as a small hobby project with no serious intentions. But in the years that followed, it grew to a mature webserver with unique and proven security features. Unfortunately, lack of interest in this project has always been a seamy side. Many times, I wondered whether I should keep going on with the project or not, but somehow I always found a reason to continue. But not this time. Recently, a serious issue was found in the Hiawatha webserver and the fact that I didn't care much, made me realize that it's time to stop.

Does this mean that the Hiawatha webserver will stop to exist? No. I still use it myself a lot and I will continue to do so in the future. I will make new releases available via this website and GitLab, but don't expect any more fancy. The most important change is that I will stop seeing and promoting it as an alternative webserver. For the time being, this website will remain online, but I will make the forum read-only. The contact form will be removed, I won't send any more newsletters (I will remove all e-mail addresses soon) and I will no long be available for support questions about the Hiawatha webserver. Security related issues can still be reported, of course.

The most important reason for this is that my spare time is only limited and I'd rather spend it doing other things than developing a webserver. I recently bought an electric guitar and many of my spare time now goes to playing music. And for quite some time, I found a more interesting challenge in organisational security-related subjects and privacy-related subjects than in technical security-related subjects. For the last 6 years, I developed a methodology for performing a risk analysis for information security (in Dutch) and for the last few months, that project is suddenly going very well. It's getting a lot of attention in the Netherlands. And with a friend, I started a weblog about privacy (also in Dutch). And that simply covers most of my spare time.

So, can you continue using the Hiawatha webserver? Well, that depends on what you want from a webserver. Clearly, Hiawatha will never support HTTP/2 or HTTP/3. If you're fine with that and Hiawatha serves your needs, you can continue using it. To be clear: I won't stop developing Hiawatha. But new features will be based on what I need, not on what is needed for a webserver in general.

I now come to the end of my, probably, final message at the Hiawatha weblog. While typing this message, I realize that it's still a serious step for me. But I think it's the right one. Thanks to all who have supported me and this project (you know who you are). Hopefully, Hiawatha will serve you well for as long as possible, but I won't blame you if you switch to another webserver. Thanks and stay safe!

I've released version 10.9 of the Hiawatha webserver. In this version, the installation of the Let's Encrypt script has been integrated in the build system. The script has been renamed to lefh (Let's Encrypt For Hiawatha) and it now has its own manual page.

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.