5 ms·

We wrote a blog post: The perfect SSL nginx configuration (http://blog.commando.io/the-perfect-nginx-ssl-configuration/ http://blog.commando.io/the-perfect-ngin

We wrote a blog post: The perfect SSL nginx configuration (http://blog.commando.io/the-perfect-nginx-ssl-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.

leeoniya 12y ago
this: https://gist.github.com/plentz/6737338 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)
nodesocket 12y ago
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; }
- nuxi7 12y ago
  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.
  - wolf550e 12y ago
    2048 bit DHE breaks java 6, but is only PFS option for recent msie on windows. A tradeoff worth making.
    - skuhn 12y ago
      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&version=8&platform=XP https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...
      - yuhong 12y ago
        It doesn't work either because it depends on DSA certificates.
        skuhn 12y ago
        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.
        kryptiskt 12y ago
        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.
fletchowns 12y ago
Some other useful resources: https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...
geofft 12y ago
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.
- agwa 12y ago
  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 https://news.ycombinator.com/item?id=8473626
  - geofft 12y ago
    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.
- lstamour 12y ago
  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.
  - geofft 12y ago
    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.
bryogenic 12y ago
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";
- nodesocket 12y ago
  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{}.
thaumaturgy 12y ago
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.
teekert 12y ago
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?
- diafygi 12y ago
  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.com https://www.ssllabs.com/ssltest/analyze.html?d=utilityapi.co... [2]: https://www.startssl.com/certs/class1/sha2/pem/ https://www.startssl.com/certs/class1/sha2/pem/ [3]: https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightpirates.org https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightp...
  - tombrossman 12y ago
    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.com https://www.ssllabs.com/ssltest/analyze.html?d=brossmanit.co... [1]https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS [2]https://letsencrypt.org/ https://letsencrypt.org/
deleted 12y ago
[deleted]
- yuhong 12y ago
  You can use 3DES instead of RC4, but this cipher is one of the slowest ones.
sschueller 12y ago
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 https://www.ssllabs.com/ssltest/analyze.html?d=techdroid.com

leeoniya 12y ago

this: https://gist.github.com/plentz/6737338 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)

nodesocket 12y ago

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; }

nuxi7 12y ago
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.
- wolf550e 12y ago
  2048 bit DHE breaks java 6, but is only PFS option for recent msie on windows. A tradeoff worth making.
  - skuhn 12y ago
    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&version=8&platform=XP https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...
    - yuhong 12y ago
      It doesn't work either because it depends on DSA certificates.
      - skuhn 12y ago
        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.
        kryptiskt 12y ago
        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.

fletchowns 12y ago

Some other useful resources: https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...

geofft 12y ago

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.

agwa 12y ago
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 https://news.ycombinator.com/item?id=8473626
- geofft 12y ago
  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.
lstamour 12y ago
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.
- geofft 12y ago
  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.

bryogenic 12y ago

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";

nodesocket 12y ago
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{}.

thaumaturgy 12y ago

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.

teekert 12y ago

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?

diafygi 12y ago
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.com https://www.ssllabs.com/ssltest/analyze.html?d=utilityapi.co... [2]: https://www.startssl.com/certs/class1/sha2/pem/ https://www.startssl.com/certs/class1/sha2/pem/ [3]: https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightpirates.org https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightp...
- tombrossman 12y ago
  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.com https://www.ssllabs.com/ssltest/analyze.html?d=brossmanit.co... [1]https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS [2]https://letsencrypt.org/ https://letsencrypt.org/

deleted 12y ago

[deleted]

yuhong 12y ago
You can use 3DES instead of RC4, but this cipher is one of the slowest ones.

sschueller 12y ago

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 https://www.ssllabs.com/ssltest/analyze.html?d=techdroid.com