14 February 2010, 08:10

Hiawatha 7.0 has been released! With this version, can you monitor multiple instances of the webserver from a central place. This makes Hiawatha more suitable for large scale deployments and enterprise solutions.

There are two features, for which I often recieve a request, which I would like to discuss with you. One is on-the-fly-gzip content encoding and the other is Server Name Indication, which makes it possible to use multiple SSL certificates on one binding.

  • First, on-the-fly gzip content encoding. The main problem with this one is that it requires Hiawatha to completly buffer the output of a HTTP request. Buffering the output in memory will cause memory problems for busy websites with large files or CGI's that generate large output. Buffering the output to disk will make it significantly slower. For me, both options are unacceptable.

    Most users of Hiawatha, including me, use PHP. PHP has support for automaticly gzipping the output. Images are hard to compress and CSS files are mostly small and therefor not much is gained by compress those. For all these reasons, I have decided not to implement on-the-fly gzip content encoding support.

  • Second is Server Name Indication, or SNI. I really would like to implement this one, but the OpenSSL documentation is incomplete and horrible. I've tried to understand how SNI works in OpenSSL, but weren't able to figure it out. If any OpenSSL expert out there can explain it to me, I will try again. But until then, I'm not going to waste any more time on this one.

    My guess is that IPv6, which will make SNI obsolete because every machine will have more than enough IP addresses, will become more mainstream before OpenSSL has some proper documentation.

14 February 2010, 15:34
First of all thank you very much for this nice update. I understand and appreciate your explanations on the two issues and fully agree with you. (just a side note: please sign your downloads/releases in the future with PGP and publish also Hash keys).
Hugo Leisink
14 February 2010, 15:46
How is signing the files and publishing the hashes going to make Hiawatha more trustworthy? Since we never met and exchanged PGP keys, you have to download my public key. Simply downloading my public key makes the signature worthless. And publishing file hashes... well, if a man-in-the-middle can change the source tarball while you're downloading, he surely can change the hash.
19 February 2010, 08:27
Sure. This is all right so far. Regarding the PGP keys. I might want to download the key and write you an e-mail or you add your fingerprint in the answer of a blog post or an IRC chat. It is not that easy to forge a PGP key if you use the same key over some time and for different things.

Regarding the hashes you are wrong about that. Changing the file during simple ftp/httpdownloading might be easy. Changing the published Hash key during opening of your SSL encrypted homepage is very hard unless there is a security issue with your webserver :-)
Hugo Leisink
19 February 2010, 11:01
You method does surely increase the reliability of the PGP key. But then again, does that make Hiawatha more thrustworthy? What if I included a backdoor in Hiawatha? A PGP key does not prevent that.

About the hashes: you are wrong An SSL connection might prevent other people from changing the content, but what certainty do you have about the end-point. How do you know you are communicating with the webserver of the Hiawatha website and not with a man-in-the-middle?

Whether Hiawatha is safe and secure enough is totally up to you to decide. No PGP, hash or SSL connection can do that for you.