Skip to content

development

Automatic builds with jenkins

We have been using jenkins to build lighttpd2 (normal build, snapshots, packages, docs, and gerrit pull requests).

From now on we are also building lighttpd-1.4.x, spawn-fcgi, fcgi-cgi, scgi-cgi, fcgi-debug, multiwatch and weighttp.

All this has been implemented in a very generic way, so our gerrit instance might see some of the other projects soon too. It also should be very easy to add more projects to this setup (although creating the initial packaging usually requires still some work).

As the gnutls package in debian jessie was very important for lighttpd2 but build.opensuse.org doesn’t support debian testing, we built our own debian packages back when jessie was still testing. Because it was very easy to reuse this we now provide debian packages (jessie/stable + stretch/testing) for the other projects too, and you can find packages for other distributions in OBS home:stbuehler:*.

The nightly packages are created after every commit (when the build succeeded), the normal packages are build after manual triggering in jenkins (we will publish releases candidates this way).

Mitigating BEAST attack on TLS with GnuTLS

In our lighttpd 2 development branch we use modules to implement SSL support; this allows us to support different ssl libraries, and today I want to talk about mod_gnutls.

SSL/TLS had some trouble. On the one hand there is the BEAST attack, which recommends using RC4 for SSL3.0 and TLS1.0 connections and on the other hand RC4 in TLS is broken.

So while some clients may support TLS1.1 or even TLS1.2, you still have to support RC4 for those which don’t, but you also don’t want to allow RC4 for clients that support TLS1.1 or TLS1.2. Most server configurations can’t handle that - but mod_gnutls can, using a nice hook function1 in GnuTLS (PolarSSL supports this directly too, and Hiawatha is using it).

Basically it will just append ":-CIPHER-ALL:+ARCFOUR-128" to your priority string (similar to ciphers in OpenSSL) if the connection uses TLS1.0 or SSL3.0.

I recommend "NORMAL:-VERS-SSL3.0:-CIPHER-ALL:-SHA1:-MD5:+SHA1:+AES-256-GCM:+AES-256-CBC:+CAMELLIA-256-CBC:%SERVER_PRECEDENCE" as priority string for GnuTLS in lighttpd2, and mod_gnutls will fix BEAST for you:

  • SSL3.0 is disabled - all clients should at least support TLS1.0 now
  • -SHA1:-MD5:+SHA1 reorders the ciphers so that SHA1 comes later and removes MD5 ciphers (there is only one supported MD5 cipher: TLS_RSA_ARCFOUR_MD5)
  • -CIPHER-ALL:+AES-256-GCM:+AES-256-CBC:+CAMELLIA-256-CBC selects the 3 ciphers we’d like to support. You could also add 128-bit ciphers if you want: :+AES-128-GCM:+AES-128-CBC:+CAMELLIA-128-CBC.
  • %SERVER_PRECEDENCE tells the GnuTLS server to reorder the ciphers to its own preference.
  • You could add “:-RSA” to force DHE/ECDHE key exchanges which should provide perfect forward secrecy.

The recommended priority string should result in the following cipher list:

TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1
TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_256_CBC_SHA1
TLS_DHE_RSA_AES_256_CBC_SHA256
TLS_DHE_RSA_AES_256_CBC_SHA1
TLS_DHE_RSA_CAMELLIA_256_CBC_SHA1
TLS_DHE_DSS_AES_256_CBC_SHA256
TLS_DHE_DSS_AES_256_CBC_SHA1
TLS_DHE_DSS_CAMELLIA_256_CBC_SHA1
TLS_RSA_AES_256_CBC_SHA256
TLS_RSA_AES_256_CBC_SHA1
TLS_RSA_CAMELLIA_256_CBC_SHA1

For TLS1.0 it will use this instead (SSL3.0 is disabled):

TLS_DHE_DSS_ARCFOUR_SHA1
TLS_RSA_ARCFOUR_SHA1

With a standard RSA key it will use the following ciphers (update: we now support DHE):

TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_256_CBC_SHA1
TLS_DHE_RSA_AES_256_CBC_SHA256
TLS_DHE_RSA_AES_256_CBC_SHA1
TLS_DHE_RSA_CAMELLIA_256_CBC_SHA1
TLS_RSA_AES_256_CBC_SHA256
TLS_RSA_AES_256_CBC_SHA1
TLS_RSA_CAMELLIA_256_CBC_SHA1

and for TLS1.0:

TLS_RSA_ARCFOUR_SHA1

lighttpd 2 config example:

setup {
    module_load "mod_gnutls";
    gnutls [
        "priority" => "NORMAL:-VERS-SSL3.0:-CIPHER-ALL:-SHA1:-MD5:+SHA1:+AES-256-GCM:+AES-256-CBC:+CAMELLIA-256-CBC:%SERVER_PRECEDENCE",
        "listen" => "0.0.0.0:443",
        "pemfile" => "/ssl/certs/lighttpd_server.pem"
    ];
}

Now you can test your server (needs a recent enough version of GnuTLS that at least includes support for TLS1.1, tested with gnutls 3.0.22):

gnutls-cli --priority="NORMAL:-CIPHER-ALL:+ARCFOUR-128" example.com
gnutls-cli --priority="NORMAL:-CIPHER-ALL:+ARCFOUR-128:-VERS-TLS-ALL:+VERS-TLS1.0" example.com
gnutls-cli --priority="NORMAL:-ARCFOUR-128:-VERS-TLS-ALL:+VERS-TLS1.0" example.com

The first one should fail; GnuTLS should use TLS1.2 to connect, and RC4 won’t be available. The second command should work - it should use TLS1.0 to connect, and only RC4 should be available, and that is why the third one should fail again.

Qualys SSL Labs Server Test should detect this setup, it will show the "SSL_RSA_WITH_RC4_128_MD5" under “Suites used only for BEAST mitigation (TLS 1.0 and earlier)”.

Meanwhile…

Hey folks,

back in december, we posted about a new lighty branch and opened up our project to the public:
https://redmine.lighttpd.net/wiki/lighttpd-sandbox

It’s still not in a fully useable state yet, but we have been very busy and made huge progress meanwhile.
Look what we had last time:

Dec 08:

  • the config handling is pretty complete
  • basic connection handling including throttling and keep-alive/IO timeouts works
  • error logging works (introducing multiple error log levels and targets)
  • module/plugin interface mostly done
  • completely multithreaded
  • serves static files

Apart from some minor features we can now say the core is almost done with just small changes or optimizations to it.
We now start to add functionality to the core via modules and following ones already work pretty well:

  • mod_accesslog
  • mod_auth (auth-basic with plaintext files working)
  • mod_dirlist
  • mod_expire
  • mod_fastcgi (working pretty well already, giving usability a big boost!)
  • mod_openssl (ssl functionality provided through openssl)
  • mod_redirect (more powerful than in 1.x)
  • mod_rewrite (also more powerful than in 1.x)
  • mod_status
  • mod_vhost (virtual hosts, plenty of options and possibilities; combines mod_simple_vhost and mod_evhost plus more)

Performance seems to be really great so far. Thanks to being fully multithreaded, lighty 2.0 scales nicely with multicore CPUs.
It can handle several hundred thousand requests per second on a new Intel i7 (for really small static files, on localhost, not a great benchmark :P).

Let me tell you, alot has changed! And of course you’re welcome to test and have a look at its current state. But - just like last time - the forum as well as ticket/issue tracking is still disabled for it because we are not capable of providing any support as well as getting things done within a reasonable amount of time - so we focus on getting things done. :)

Some people might already be able to do basic stuff like serving static files, maybe play with fastcgi a little. As the config and design completely differs from 1.x you might already want to take a look or “test ride”. Remember: No support at the moment. :-)

We can’t (and really don’t want to) provide any specific release date but hope to have 2.0 in a usable state by the end of the year.
Remember we do this in our free time for fun.

As for lighty 1.4 and 1.5: everything will continue like before - no worries.

This is it for today.

Thanks for flying light.

spawn-fcgi removed from lighttpd src

As announced in an earlier post, spawn-fcgi has now been removed from the lighttpd tree.
spawn-fcgi has become a completely seperate project (located at https://redmine.lighttpd.net/projects/spawn-fcgi/wiki)

Lighty 1.4 can still spawn fastcgi processes internally via mod_fastcgi of course.

Package maintainers are advised to provide packages for spawn-fcgi, to make it a dependency of lighttpd and to remove the binary from any existing package as soon as possible so spawn-fcgi can be updated even when there is no new lighttpd release.

Lighttpd 1.4.23 will not include the binary anymore.

Prerelease of spawn-fcgi 1.6.0 (rc1-r16)

spawn-fcgi extracted into own project

There are several versions of spawn-fcgi (one in lighttpd 1.4.x, one in 1.5.x and one in cherokee), which makes packaging very hard (e.g.: debian packages spawn-fcgi from lighty as “spawn-fcgi.lighttpd” - making usage complicated as your scripts are probably just using “spawn-fcgi”).
Additionally, keeping the sources and bug fixes synchronized is just too much work (ok, the one in cherokee isn’t our problem :) ).
Therefore we decided to split spawn-fcgi into a new project which will start with version 1.6.0 (and will be independent of lighttpd releases or versions).

We plan to remove spawn-fcgi from lighttpd-1.4.x after the release of 1.4.22.

In case you would like to test a spawn-fcgi version with more features (options for chowning the socket), see here: https://git.stbuehler.de/stbuehler/spawn-fcgi2 (needs glib)

You can find the new project at https://redmine.lighttpd.net/projects/spawn-fcgi/wiki

A little heads up

Hey folks,

back in july, I posted about a new lighty branch we planned on creating. A complete rewrite with a new core design.
There haven’t been any posts since then about it and you might wonder if it lead to anything.

Well, roughly 4 months, 256 commits and 14 thousand lines of code later, we are at a point at which we have something to show you.
We just opened up our project in redmine to the public: https://redmine.lighttpd.net/wiki/lighttpd-sandbox
You can take a look around and browse the source.
We call it “sandbox” because there is one thing we want to really stress: it is not in a useable state yet. Boards as well as ticket/issue tracking have been disabled for it because we are not capable of providing any support at this point.
I repeat: NO SUPPORT FOR SANDBOX
So what state is it in exactly?

  • the config handling is pretty complete
  • basic connection handling including throttling and keep-alive/IO timeouts works
  • error logging works (introducing multiple error log levels and targets)
  • module/plugin interface mostly done
  • completely multithreaded
  • serves static files

I am currently working on the new mod_accesslog. It is already capable of what the 1.x version can but I wanted to expand it a little bit.
A feature that might be quite usefull: have different log formats and targets depending on the status code of the request. This way, you can for example log all request resulting in a 400 or 500 to a special file with addition information you would normally not log.
But I have trouble finding the right way to express that in the config in a good way. This is the perfect moment to get you users out there involved. I’d really like to hear your suggestions so please leave a comment with your ideas. Take a look at the config documention in the sandbox wiki to know what you can use.

A lot of work has been done and there is even more still ahead. It really takes a lot of time and hopefully it will pay off some day.\

So much for the bleeding edge part. About 1.x: There will probably be a 1.4.21 (pre)release soon. Watch out :)

We really would appretiate if more users would test our prereleases and report back to us if they find any issues. It’s crucial in order to bring you well-tested and stable releases.
A thank you to all the people who did this in the past at this point!

This is it for today.

Thanks for using lighty.

delay request handling for stupid crawlers

I’m sure you know what “Crawl-Delay” is, but you may or may not know that, not all search engine crawlers support this nice stuff.

What to do for those don’t obey the instrustion? They’ll eat all your Mbits/month or slow your webserver down. OK, ban it with url.access-deny. This is the only option u can choose before. But you don’t want to remove your pages from the stupid search engine index, do you?

Here comes another option for you: with this patch, u can delay handling of a specified request for some seconds. Example configuration:

$HTTP["user-agent"] =~ "stupid-crawler" {
    connection.delay-seconds = 2
}

OK, here’s the link to the lighttpd-2296-request-handle-delay.patch which applies to branches/lighttpd-1.4.x@2296

Be aware that this patch is to be reviewed before commited to repo.

Growing the team

The dev team has gotten some new members recently that you might not know of. Here’s a heads up (in alphabetical order):

  • hoffie
  • icy
  • nitrox
  • stbuehler

If you hang out in #lighttpd, you will already know these names.

That being said, there is also some news about the state of the development of lighty.

Lighty is a great webserver and we all love it. But if you use it for quite some time, you’ll eventually find out that it’s not perfect. There are some oddities and shortcomings that cannot be ironed out without rewriting a significant part of the core.

This is where I had the idea to start all over.
With lessons learned from the past, we could write a new version of lighty that fixes the design issues the current versions have. But at the same time keep all the good stuff and remain fairly compatible.
The main idea to be fast and lightweight is still valid and if you are familiar with 1.4.x or 1.5, you will have no problems with the new version.

Jan had the idea to use glib for stuff like strings/buffers and arrays. He wanted to rewrite the corresponding parts and did so in a branch of his.
I proposed to take this even further and use glib throughout the source. It makes coding easier, faster and in the end more secure because you can rely on proven and well tested source.

stbuehler jumped in and created a new branch where he started to hack on an all new lighty using the ideas from above. The following days we discussed a lot - and still do so - about the new design. What we could do better, what shortcomings we wanted to fix.

The result is nothing less but a more flexible and faster design for lighty.

This sounds awesome but where is the catch you might think.
Well, currently we have not too much code ready but we are actively hacking on it. Do not ask when it will be released, there is no estimated date. We are still at the very beginning of the new version but hope to have it some day become the official Lighttpd 2.0

We created a “Plans_for_2_0” page that lists some of the (technical) plans we currently have. You might find some of them interesting.

This is it for today folks. Hope you like the route we are taking and maybe drop us a line in #lighttpd or in the comments.

- update -

To make it clear: 1.5 or 1..4 have not been dropped. If you think 1.5 is unstable and you get a segfault or something like that, then tell us. File a ticket, attach a stacktrace and document the problem in a detailed way so it can be fixed. Thanks for using lighty.

GSoC: collecting ideas

Google is doing a the Summer of Code again and I was approached from different sides to participate this year. There is already a lot going on in SVN again working towards a new 1.4.19 release, but for the future we want to attract more developers for more new, great features.

Before I submit the application request I would like to collect some more ideas what we would like to see to be done. At GSoC2008/Ideas I added my short list of projects that I would like to mentor.

If you would like to be a mentor too, please add your own list.

  • Documentation improvements
  • Integration into web-panels
  • maintaining the OpenWRT port

are just some small ideas where we could take help from non-developers.