Hacker News Reader

Comment by nodesocket | Hacker News Reader

We wrote a blog post: The perfect SSL nginx configuration (http://blog.commando.io/the-perfect-nginx-ssl-configuration/) which details all the nginx directives to set to achieve an A+ rating on sslLabs, including mitigation of FREAK, POODLE, and HEARTBLEED.

View on HN

Hmm, as a novice, capable of setting up fine Drupal/Nginx/mail(Postfix) server I'm kind of shocked to get an F rating on ssllabs with the default, up to date, ssl enabled, Debian/Nginx config... Sounds like something to fix, not? Is there that much need for some forms of backwards compatibility? Are A+ servers badly reachable from older browsers or something? Why would the default be so bad? Somehow, in all my naivety I have always thought regular apt-get update/upgrades would keep me secure. Seems I'm still vulnerable to POODLE even. Guess I'll have to keep checking next to updating. Should I delete old config files with every update? Are new ones containing the recommended settings?

Here's the how we get an A+ rating[1] for nginx on utilityapi.com:

    ssl on;
    ssl_certificate my_ssl.crt;
    ssl_certificate_key my_ssl.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers EECDH+aRSA+AES256:EDH+aRSA+AES256:EECDH+aRSA+AES128:EDH+aRSA+AES128;
    ssl_session_cache shared:SSL:50m;
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security max-age=63072000;

Our configuration doesn't support for IE6 or IE8 on Windows XP, but that's the only downside. Also, this configuration has 100% forward secrecy :)

Finally, you can get an A+ rating for free with StartSSL's free option, then using the SHA2 intermediate certificate[2]. This is what I use for my pgp keyserver[3].

[1]: https://www.ssllabs.com/ssltest/analyze.html?d=utilityapi.co...

[2]: https://www.startssl.com/certs/class1/sha2/pem/

[3]: https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightp...

You can keep your A+ and add IE8 on XP, plus boost your key exchange to 100%[0], by following Mozilla's TLS docs[1] and sticking with the default Intermediate ciphersuite.

You might also consider disabling server tokens to hide your Nginx version (server_tokens off;) for a bit of 'security through obscurity' and enabling SPDY (listen 443 ssl spdy;) for a performance boost.

Also worth pointing out is the upcoming Let's Encrypt project[2] which will make domain validated certificates free soon.

[0]https://www.ssllabs.com/ssltest/analyze.html?d=brossmanit.co... [1]https://wiki.mozilla.org/Security/Server_Side_TLS [2]https://letsencrypt.org/

I think using Mozilla's "Modern cipher suite" list should do it, and it seems to be all forward secure:

https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_com...

What prevents me from using 'Modern' is it requires Android 4.4+, which excludes a hell of a lot of mobile users. I'm okay with dropping XP support but dropping Android 4.3 and earlier is too limiting for me.

I'm not wild about having non-FS options that a man in the middle could force a downgrade to. IE8 on XP isn't worth it.

The problem here is not "how to have a secure configuration", it's really "why is it not secure by default"; we actually need more "secure by default" because it largely reduces the chances of doing it wrong.

I have an up-to-date nginx on wheezy, stock debian packages, no more than just `listen $IP ssl ; ssl_certificate ; ssl_certificate_key` directives and it gets an A on ssllabs.

Do you know exactly what problem you had? It might have been unrelated to debian's presets.

EDIT: a different server with a many-times-upgraded nginx package (but same version) has no `ssl_protocols` in /etc/nginx/nginx.conf and so had SSLv3 enabled. So i agree that this can happen. In my case it's probably a consequence of silent upgrades and `Dpkg::Options::=--force-conf{def,new,old}` choosing to preserve existing config files.

These are the ones pulling down the grade: - This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C. MORE INFO » - This server supports anonymous (insecure) suites (see below for details). Grade set to F. - The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B. - This server accepts the RC4 cipher, which is weak. Grade capped to B. MORE INFO »

The server was installed quite some time ago on Digital Ocean, it could be that I just need the most recent default Nginx configs. I'll test. Btw, I have a startssl cert, should have choosen the www subdomain though, not "mail". I'll do an apt-get purge nginx before reinstalling and than manually add back the old settings.

You should have a configuration file ending in .dpkg-new with whatever settings the modern nginx package provides, no need to purge and reinstall.

Thank you for taking the time to do that. But, would you consider adding to the article a bit? I come from the slightly older "never run a command you don't understand" school of systems administration. Your second section is OK at describing what's going on in the configuration file, but the first section is a bit sparse.

It's still a helpful starting point though.

Some other useful resources:

https://wiki.mozilla.org/Security/Server_Side_TLS

https://mozilla.github.io/server-side-tls/ssl-config-generat...

Ugh. I've seen servers with single-DES-only because they had a state-of-the-art config file in the 1990s that nobody had ever touched later. While I appreciate the intent behind efforts like this, I'm really uncomfortable with advice to configure your server with certain ciphers by name, and not make a plan for checking regularly whether that's still correct.

Does merely "!EXP" not work for this? The intent behind OpenSSL's groups is to avoid exactly this problem.

I'm troubled by this too. Unfortunately, Ivan Ristic has come to the conclusion that it's not possible to build future-proof cipher suite configuration in a generic way:

https://news.ycombinator.com/item?id=8473626

Yeah, I think "We agitated to make this the default in the upstream project" would be a fantastic way to solve this problem.

"We're providing builds that are patched to have better defaults" or "We're providing a git repository / config management host / something that has an always up-to-date config snippet" might also be okay, as would "Please check back to this blog post regularly". It's the static post that makes me sad.

You'll have to keep up to date in your server config in other areas, however, including disabling attack surface area and staying up to date and fully patched. Security is never set-it-and-forget-it and that's the real problem with "state-of-the-art config" files. After you fix this manually, find a way to automate such deployments and sign up for a bunch of mailing lists or RSS feeds. Monitoring would be nice but awareness is a start.

Staying fully patched, at least in theory, involves taking new sources or binaries from the same source on a regular basis. If we could push config like this in the same fashion, I'd be thrilled (whether that involves them coming from the people who get you your sources/binaries, or from a third party). I just worry that someone's going to follow this advice and then leave their job in a few months, and the next person maintaining the system won't even realize that the cipher suites are customized from the upstream defaults. It's not a particularly normal thing to configure.

That's where (hopefully) the automating part comes in: a file, checked in to version control, that clearly says what's changed. But this is also where automatically patched vulnerability scanners could play a role, just as you'd want to check configurations periodically to be sure no one's gone in with SSH manually...

If you want 100% on all categories (not recommend, you will prevent a lot of browser from using SSL) you will need to turn off everything other than TLS 1.2 and remove all ciphers that are lower than 256 bits. You will also need a 4096 bits certificate with SHA256.

  ssl on;
  ssl_certificate      ssl.nginx;
  ssl_certificate_key  ssl.key;
  ssl_dhparam dhparam.pem;
  ssl_protocols TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_ciphers '!ECDHE-RSA-AES128-GCM-SHA256:!ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:!DHE-RSA-AES128-GCM-SHA256:!DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:!ECDHE-RSA-AES128-SHA256:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-RSA-AES128-SHA:!ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES128-SHA:!DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!AES128-GCM-SHA256:AES256-GCM-SHA384:!AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!AES128-SHA256:!DES-CBC3-SHA:!CAMELLIA128-SHA:!DHE-RSA-CAMELLIA128-SHA';
  ssl_session_cache    shared:SSL:10m;
  ssl_session_timeout  10m;

https://www.ssllabs.com/ssltest/analyze.html?d=techdroid.com

this: https://gist.github.com/plentz/6737338

start with this.

if you don't need the compat, use a cipher suite without RC4 (as in the parent post)

In addition to your configs I had to enable HSTS to achieve an A+ Add to a server section:

  add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

We left out http headers, because that usually can be done at the application level, or in location{} blocks in nginx. I wouldn't recommend setting headers globally in http{}.

Didn't know about setting DH parameters.

On each server, do the following:

    sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

Then in nginx.conf set:

    http {
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    }

Non-EC DHE is basically dead. The param size isn't part of the TLS handshake and so using a larger size actually breaks some clients that only do 1024-bit DH params. At the end of the day, almost all the clients that support larger DH param sizes also support ECDHE, which is faster anyway. You might as well not bother and just keep a few non-PFS ciphers for those clients to avoid interoperability problems.

Bonus trivia: ssh-dss (SSH DSA keys) has vaguely similar problem, which they considered fixing but decided instead to simply not repeat the mistakes when writing the SSH ECDSA spec. This is why ssh-dss keys are effectively limited to 1024-bit.

2048 bit DHE breaks java 6, but is only PFS option for recent msie on windows. A tradeoff worth making.

Well, DHE is the only PFS option for IE on Windows XP. Vista, 7 and 8 all support ECDHE.

IE8 on XP is basically totally busted:

https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...

It doesn't work either because it depends on DSA certificates.

Yep. Time to give up on anyone using a browser that depends on XP's SSL support. Much like SSLv3, they will get the message when the entire Internet stops loading in their browser.

They will get the message to randomly download some thing from the net that fixes their problem, if they're lucky it will be as well-behaved as Superfish.

Reply on news.ycombinator.com