lighty's life

lighty developer blog

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).

PRE-RELEASE: Lighttpd 1.4.33rc1-r2901

We would like to draw your attention to the latest pre-release of the stable 1.4 branch of lighttpd.

You can get the pre-release from these urls:

Please test it as much as possible and provide us with feedback.
A lot of testing ensures a good release.

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 1, which recommends using RC4 for SSL3.0 and TLS1.0 connections and on the other hand RC4 in TLS is broken 2.

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 function3 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 4 (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 5 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)”.

1 Mitigating the BEAST attack on TLS

2 RC4 in TLS is Broken: Now What?

3 gnutls_handshake_set_post_client_hello_function

4 GnuTLS Priority Strings

5 Qualys SSL Labs Server Test