Hiawatha webserver

The IETF HTTP Working Group has approved the HTTP/2 specification. This draft will now get the 'request-for-comments' status for a short while, which allows others to make their comments. After that, the IETF will publish it as an official standard.

The IETF HTTP Working Group has approved the HTTP/2 specification. This draft will now get the 'request-for-comments' status for a short while, which allows others to make their comments. After that, the IETF will publish it as an official standard. Update: The HTTP/2 RFC has been published in May 2015.

After every release, I always think: what's next? But somehow, there is always something to improve or fix. This new release of the Hiawatha webserver contains two main changes. First, Hiawatha now uses mbed TLS instead of PolarSSL. What, a new SSL ... [More] library? No, PolarSSL has been acquired by ARM, so PolarSSL has been rebranded as mbed TLS. The effect of this name change is that Hiawatha can no longer support earlier versions of PolarSSL, because several changes has been done to the code. mbed TLS 1.3.10 uses both polarssl and mbedtls in the code (quite confusing), but a/the next release of mbed TLS will contain no reference to the name PolarSSL any more. So, also a/the next release of Hiawatha will no longer support earlier version of mbed TLS. The Hiawatha SSL library (not PolarSSL / mbed TLS itself) contained a memory leak, which occured when a client tried to connect with SSL3.0, while support for it was turned off or not included at all. For every 'No cypher overlap during SSL handshake.' in your system.log, there was a small leak. But when someone did a large amount of SSL3.0 connection attempts to your server, you could have problem. I therefor advice everyone to update to v9.12. The leak was by the way very easy to find via the XCode tool Instruments, which is an awesome tool! [Less]

After every release, I always think: what's next? But somehow, there is always something to improve or fix. This new release of the Hiawatha webserver contains two main changes. First, Hiawatha now uses mbed TLS instead of PolarSSL. What, a new SSL ... [More] library? No, PolarSSL has been acquired by ARM, so PolarSSL has been rebranded as mbed TLS. The effect of this name change is that Hiawatha can no longer support earlier versions of PolarSSL, because several changes has been done to the code. mbed TLS 1.3.10 uses both polarssl and mbedtls in the code (quite confusing), but a/the next release of mbed TLS will contain no reference to the name PolarSSL any more. So, also a/the next release of Hiawatha will no longer support earlier version of mbed TLS. The Hiawatha SSL library (not PolarSSL / mbed TLS itself) contained a memory leak, which occured when a client tried to connect with SSL3.0, while support for it was turned off or not included at all. For every 'No cypher overlap during SSL handshake.' in your system.log, there was a small leak. But when someone did a large amount of SSL3.0 connection attempts to your server, you could have problem. I therefor advice everyone to update to v9.12. The leak was, by the way, very easy to find via the XCode tool Instruments, which is an awesome tool! [Less]

After every release, I always think: what's next? But somehow, there is always something to improve or fix. This new release of the Hiawatha webserver contains two main changes. First, Hiawatha now uses mbed TLS instead of PolarSSL. What, a new SSL ... [More] library? No, PolarSSL has been acquired by ARM, so PolarSSL has been rebranded as mbed TLS. The effect of this name change is that Hiawatha can no longer support earlier versions of PolarSSL, because several changes has been done to the code. mbed TLS 1.3.10 uses both polarssl and mbedtls in the code (quite confusing), but a/the next release of mbed TLS will contain no reference to the name PolarSSL any more. So, also a/the next release of Hiawatha will no longer support earlier version of mbed TLS. The Hiawatha SSL library (not PolarSSL / mbed TLS itself) contained a memory leak, which occured when a client tried to connect with SSL3.0, while support for it was turned off or not included at all. For every 'No cypher overlap during SSL handshake.' in your system.log, there was a small leak. But when someone did a large amount of SSL3.0 connection attempts to your server, you could have problem. I therefor advice everyone to update to v9.12. The leak was, by the way, very easy to find via the XCode tool Instruments, which is an awesome tool! [Less]

Version 9.11 of the Hiawatha webserver has been released. This release brings the ChallengeClient option, which gives Hiawatha the ability to reduce the effects of a DDoS attack. This is done by checking if the client has a certain cookie set. If ... [More] this is not the case for the first request within a connection, Hiawatha sends a 307 and this cookie (via a Set-Cookie HTTP header or a Javascript) back to the client. If the second request within a connection doesn't has this cookie, the client is banned. The idea is that normal browsers understand the 307 and the HTTP Set-Cookie header or the Javascript, but HTTP bots don't. Please note that this although this option works from a technical point of view, it should be used with great care. Proper testing is strongly advised. Also note that this option should only be used when options like ConnectionsPerIP, ReconnectDelay and BanOnFlooding are insufficient. Many thanks to Andrey Vasilev and Chris Wadge for all the testing and feedback. [Less]

The 9.10-rc1 release caused no trouble for anyone, so here is the final release. Nothing changed. Have fun with it!

The first release candidate of version 9.10 has been released. In this version some significant changes have been made. This requires careful testing, so please download it and help me to do the testing of the following changes. The code for ... [More] calling the UrlToolkit and the reverse proxy have been swapped. This means that you can now specify an UrlToolkit rule which will be processed before using a reverse proxy. The Expire and UseFastCGI actions have no effect when using a reverse proxy. The syntax of the UrlToolkit has been changed a bit. Main change is the introduction of the 'Do' command, which unconditionally performs an action. The command 'Call' and 'Skip' can now only be used as a action for the 'Do' command. And several commands can now be used with extra actions. See config/toolkit.conf for a complete syntax overview. This change made the UrlToolkit code a bit more simple. Easier code means less chance of a bug which means less chance of a security issue. You can now ban misconducting clients who connect via a proxy specified via the HideProxy setting. When you specify multiple reverse proxies for a virtual host, Hiawatha will first look for a matching URL pattern for the reverse proxy with a scheme matching the scheme of the client connection. So, incoming HTTPS connections will be forwarded to a HTTPS reverse proxy when available and HTTP connections to a HTTP reverse proxy when available. I'm looking forward to your feedback. Even if you didn't find any issue. The 9.10 release candidate can be found at the download page. [Less]

A new version of the Hiawatha webserver has been released. Several changes has been made to further improve the SSL capabilities of this webserver. One of those changes is the addition of the CAcertificates setting, which allows you to specify one ... [More] or more CA certificates. This allows Hiawatha to verify the authenticity of the peer in case it acts as an SSL client, which it does for a reverse proxy and websockets. It was always my idea that the reverse proxy functionality should only be used for local applications that only speak HTTP instead of the usual (Fast)CGI or for SSL offloading. SSL support was included for the rare situation where a local HTTP-speaking webapp only speaks HTTPS, for which SSL validation is not required. I think I never explained this intended usage well enough, because I found out that several people used Hiawatha's reverse proxy functionality to connect via HTTPS to other webservers via the internet. This requires SSL certificate validation to make the connection secure. That's why I included the CAcertificates option. If not set, SSL connections made by Hiawatha are not validated and therefor not really secure. Only do that for local connections or within a trusted network. Otherwise, use this option to feed Hiawatha with trusted CA certificates. [Less]

I would like to respond to a post by Chris Wadge about the security of his Hiawatha Debian packages. In his post he said he has received several questions about the security of the Hiawatha Debian packages he has made available. Although he thinks ... [More] those are valid questions, I think they are a bit weird. Questions like 'Are your packages secure?' are pointless, because would you ever expect to get 'no' for an answer? Let me first explain a bit more about security and trust. Security begins where trust ends. I trust my wife, I trust my family, I trust my friends. Of course, my wife has a key to our home, but without any doubt I would give the key to our home to any family member or a friend if it was needed in any situation. There is no need for me to take any security measures. Trust is needed to make life easier. Of course, I don't give the key to our home to a complete stranger, because I can't trust them. That's where security starts. If you think about this a bit more, you might wonder why I don't give all my friends a key to my home. I trust them, right? Yes, I do trust them completely, but I don't trust Murphy and his law, I don't trust 'bad luck' and I don't trust pickpockets. There is no need for them to permanently have a key to my home, so there is only risks and no benefit from that. So, again, security takes over. Trust is mainly based on experience, your own experience or experience by other people you already trust. I trust my friends, because in the past they've shown me to be trustworthy. People who have once abused that trust are no longer my friends. I trust my friends' judgement, so there is also some form of trust towards the friends of my friends. For some things I trust them, like lending them a movie, for other things, like giving a key to my home, I don't. Back to Chris Wadge's Debian Packages. There are two options: You decide to trust him and use his packages. You decide not to trust him (yet) and to verify the integrity of his packages (= security measure!) The case where you find a security issue in his package which is related to his packaging will be clear to everybody. But what if you don't? It will require a lot of time and knowledge to completely proof that his packaging is done securely. Unless you are willing to do this for every package he releases, you will come to a point where you decide to trust him or not. With all this in mind, I hope you understand that it's a bit weird to ask Chris Wadge about the security of his packages. I'm not going to tell whether you can trust Chris Wadge or not. That's for you to decide. All I can say is that every time we 'spoke' via e-mail, he has proven to me that he very well knows what he's talking about when it comes to IT (security) and he has always shown a very professional attitude. The rest is up to you. [Less]