Nginx cipher suite vulnerability mitigation, cipher suite order, optimizations, and questions!

Events happening in the community are now at Drupal community events on www.drupal.org.
threading_signals's picture

I was following a thread from an earlier post from perusio, but decided that starting a new thread on developing best practices for nginx https security.

Two of the links from that thread was good to know about; the one for startssl free certs, and the link for ssl testing from SSL Labs.

Noticed some issues that made me rethink the resources though. Startssl operations have been breached during the summer, while comodo apparently did not have good affiliate practices and had to get affiliate certificates revoked. In terms of price, the next best price I've found since yesterday was geotrust. Please include others worth mentioning that have better than 99~+ browser support and which has a good price.
There's also tools from sslshopper.com, which gives better chain information when checking ssl intermediate certificates, along with other tools.

SSL labs' test is nice but did not give much for the novice in figuring out what to do next. Also, with recent reports about the BEAST attack, it has placed an emphasis on better openssl and cipher suite management within nginx among other web servers. It looks as though cipher strength is not as important as cipher selection depending on recent developments. Contrary to expectations, selecting a lower strength cipher is sometimes more secure. So test suites can't replace human analysis obviously.

Openssl supposed has a workaround for the BEAST attack but I don't know how to test for that as of now, in order to get CBC ciphers in openssl working again. Openssl 1.0.1 snapshots are available so that TLS 1.1 can be enabled. Has anyone compiled that along with compiling nginx? Does it support TLS 1.2 as well? How does one set openssl so that empty fragments are sent, so the other ciphers can be used? I've found some patches to enable what looks to be ECDHE-ECDSA-AES256-SHA (non CBC?) based ciphers. Is it a better idea to patch openssl with popular patches out there?

In regards to signatures, I got Signature algorithm SHA1 with RSA with TLS 1.0. Does a stronger SHA strength only come with > TLS 1.0? Does it not matter?

A quick conf hack of nginx.conf gives me a fips enabled server after several iterations of using the "openssl ciphers" command (openssl ciphers -v '!aNULL:!CAMELLIA:!SEED:!RC4:!DES:!MD5:!EXP:HIGH:@STRENGTH'):

    ssl_ciphers !aNULL:!CAMELLIA:!RC4:!SEED:!DES:!MD5:!EXP:HIGH;

...which gives the fips "ready" response at SSL Labs with centos 6.

RC4 only is apparently: ssl_ciphers !aNULL:!CAMELLIA:!AES:!SEED:!DES:!MD5:!EXP:RC4

I checked for available RC4 ciphers with the "openssl ciphers" command, and thought PSK+RC4+SHA and KRB5+RC4+SHA is available but after restarting nginx, it doesn't appear. Anyone know why or if it is necessary? How do I prevent downgrades of ciphers or is that not possible in nginx? I noticed that nginx prefers ciphers based on the order that was put in the conf. Can more ciphers be enabled through openssl's conf?

Also fips compliance seems to be based on cipher type and protocol selection as mentioned here. How does fips compliance help most drupal shops? RC4 is not conforming to fips compliance according to what I've found.

I've tried: add_header Strict-Transport-Security "max-age=500; includeSubdomains";
...but that did not seem to be the correct syntax for nginx. What is the correct syntax/conf entry?

Ephemeral DH is set at 1024 bits. How do I change this if desired? Also, how do I get DH ciphers (using kEDH somehow?) to be served last (since they are slower)?

Did some testing and here's what I have now:

    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 SSLv3;
    ssl_ciphers !aNULL:!LOW:!MD5:!EXP:RC4:CAMELLIA:AES128:3DES:SEED:AES256;

And finally, for some ciphers, better ssl performance can be had with these patches. Does anyone have experience with these? The ciphers above is not based on the fastest ciphers that can be served. There's no reverse of the @STRENGTH command either, so there can be tweaks made. I haven't done a security assessment of the various ciphers either, or the browser compatibility of each of them.

If you can add to this thread, it will be most welcome.

Regards,

Paul

[edit3: corrected two mistakes - sorry about the email spam - drupal doesn't recognize https links apparently.]

Comments

From the mailing list

perusio's picture

here's what's being recommended as a workaround for evading BEAST on the server side:

## BEAST http://vnhacker.blogspot.com/2011/09/beast.html SSL vuln server side workaround.
## This will break IE6 and below SSL handling. Works in all other browsers. Grabbed from:
## http://mailman.nginx.org/pipermail/nginx-devel/2011-October/001311.html.

ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

It breaks SSL handling on IE6 and below.

I'll play with the FIPS and speed stuff soon. BTW there's an interesting project, stud, for SSL termination. Note that if Nginx used GnuTLS, instead of OpenSSL, TLS 1.2 would be available out of the box.

Hey, thanks for the reply. I

threading_signals's picture

Hey, thanks for the reply. I had gotten the problem sorted a few days ago by installing the snapshot version of openssl. It offers tls 1.1 only, and not 1.2, but hopefully they'll add it in the future so webservers can be ahead of the curve if anyone wants the added safeguards. If someone does compile the snapshot, they will have to recompile openssh, nginx, and any other dependencies of openssl also, if they want it working it working with their preferred system paths.

I had managed to get a fips ready response (add !SHA256 to the nginx directive depending on version of openssl, although SHA256 is better than SHA1) and then made the server run RC4, but RC4 is not fips-compliant.

Thanks for the link. I'm guessing that it can be a faster alternative to nginx's SSL module which uses openssl only and provide more options.

Firefox 7 doesn't support tls 1.1 or 1.2 from what I've read. I also tried it myself, and it wouldn't connect. It does connect to tls 1.0 RC4. about:config in firefox and filtering for security.ssl3 will give you the list of enabled/disabled booleans for ciphers.

Openssl has more options in terms of key exchanges and ciphers vs gnutls (available ciphers page). Openssl does support more non-cbc based cipher modes such as cfb and ofb but I can't tell if that would require support from browser vendors and updates by web servers. Having a separate column for cipher modes for openssl would be nice when using the 'openssl ciphers' command.

The best solution seems to be browser vendors updating first since they have better turnaround speed for this sort of problem and since your link suggests that.

RC4 is compatible with SSLv3 I think. And also, the speed patch requires purchase of a developer library. The page I mentioned linked to some samples, but I haven't dug in deep so not sure if a purchase of the library from intel is necessary.

Cheers,

Paul

Some benchmarks, and a wiki

threading_signals's picture

Some benchmarks, and a wiki page titled "Comparison of TLS implementations".

Nginx

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: