It's time for me to stop using lighttpd

May 21, 2015

There's another SSL configuration vulnerability going around; this one is called Logjam (also). Part of the suggested fixes for it is to generate your own strong Diffie-Hellman group instead of using one of the default groups, and of course another fix is yet more SSL parameter fiddling. There have been quite a lot of SSL/TLS related issues lately, and many of them have required SSL parameter fiddling at least in the short term.

I've had a long-standing flirtation with lighttpd and my personal site has used it since the start. But this latest SSL issue has crystallized something I've been feeling for a while, which is that lighttpd has not really been keeping up with the SSL times. Lighttpd cannot configure or de-configure a number of things that people want to; for example, it has no option to disable TLS v1.0 or SSL compression (although the latter is probably off in OpenSSL by now). OCSP stapling? You can forget it (from all appearances). In general, the last release of lighttpd 1.4.x was a year ago, which is an eternity in SSL best practices land.

For a while now I've been telling people when they asked me that I couldn't recommend lighttpd for new deployments if they cared about SSL security at all. Since I care increasingly much about SSL myself, it's really time for me to follow my own advice and move away from lighttpd to something else (Apache is the most likely candidate, despite practical annoyances in my environment). It'll be annoying, but in the long run it will be good for me. I'll have a SSL configuration that I have much more trust in and that is much better supported by common resources like Mozilla's SSL configuration generator and configuration guidelines.

There's certainly a part of me that regrets this, since lighttpd is a neat little idea and Apache is kind of a hulking monstrosity. But in practice, what matters on the Internet is that unmaintained software decays. Lighttpd is in practice more or less unmaintained, while Apache is very well maintained (partly because so many people use it).

(Initially I was going to write that dealing with Logjam would push me over the edge right away, but it turns out that the Logjam resources page actually has settings for lighttpd for once.)


Comments on this page:

I recently switched my personal site from raw lighttpd to haproxy+lighttpd, with haproxy 1.5 taking care of TLS termination, adding HSTS and other security headers, and bouncing people from HTTP to HTTPS. Lighttpd is bound to localhost on a different port, so that the Internet can only reach it via haproxy.

This has the gigantic plus side that I can now carve out Host+Path exceptions in haproxy that get routed to other HTTP servers, e.g. little Go servers that I'm writing, and those can still get full HTTPS support from day one. And I never have to worry about missing any of those XSS-blocking security headers.

By James (trs80) at 2015-05-21 18:56:53:

I have a feeling that Chris wouldn't be a fan of HAProxy in Layer 7 mode, for reasons: NonHTTPTransportBenefits WhyNotHTTPAsTransport

Written on 21 May 2015.
« On the modern web, ISPs are one of your threats
Unsurprisingly, Amazon is now running a mail spamming service »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu May 21 01:08:44 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.