What compatibility trade-offs do we need to make in order to use a hardened SSL config for Nginx?

Internet Explorer on Windows XP (that’s 6, 7 and 8) can’t connect because they don’t support Forward Secrecy. You can test things like this on your own over at SSLLabs.

Other than that everything should work, but there might be old mobile clients that can’t connect as well. This would need further testing.

Personally I think this configuration isn’t suitable for real world websites. AES256 is a sham and only increases the connection time. AES128 is more than good enough for normal websites, have a look at this document from Seagate. Unless you’re planning to deploy a banking website or maybe a whistle blower thingy go with AES128 and spare your server from the computing overhead.

My personal configuration for nginx looks like the following (full nginx configuration can be found in one of my repositories).

# Content Security Policy
#
# LINK: http://www.w3.org/TR/CSP/
add_header    X-WebKit-CSP              "default-src 'self' *.example.com;";
add_header    X-Content-Security-Policy "default-src 'self' *.example.com;";
add_header    Content-Security-Policy   "default-src 'self' *.example.com;";

# Do not allow embeding of our website in iframes.
#
# LINK: http://tools.ietf.org/html/rfc7034
# LINK: http://tools.ietf.org/html/draft-ietf-websec-frame-options-00
add_header X-Frame-Options "DENY";
add_header Frame-Options   "DENY";

# Only communicate view encrypted connections on all domains, forever!
#
# LINK: https://tools.ietf.org/html/rfc6797
add_header Strict-Transport-Security "max-age=262974383; includeSubdomains;";

# (Re)Enable web browser XSS filter protection (IE+Chrome).
#
# LINK: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
add_header X-XSS-Protection "1; mode=block";

# Use a public DNS to resolve OCSP responder hostnames. The answer stays valid for a complete day.
#
# LINK: http://pcsupport.about.com/od/tipstricks/a/free-public-dns-servers.htm
resolver 209.244.0.3 209.244.0.4 valid=86400;

# We only support AES128 and Elliptic curve Diffie–Hellman (ECDH) plus Diffie–Hellman (DH) in order to enable Forward
# Secrecy. This configuration ensures highest compatibility, best performance while still being extremely secure. Please
# note that using AES128 isn't really less secure than any other AES implementation.
#
# LINK: http://www.scribd.com/doc/29872766/128-Bit-vs-256-Bit-AES-Encryption
ssl_ciphers    "EECDH+AESGCM EDH+AESGCM EECDH -RC4 EDH -CAMELLIA -SEED !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !AES256";
ssl_ecdh_curve secp384r1;

# Prefer our configured ciphers over the client specified ones.
ssl_prefer_server_ciphers on;

# Only support newest protocols, unfortunately we have to support TLS 1.0 and 1.1, otherwise 99% of the internet can't
# connect to our server.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# Use a shared (among all nginx worker threads) cache for SSL sessions; one megabyte can store about 4000 sessions.
#
# LINK: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache
ssl_session_cache shared:SSL:100m;

# Number of seconds before an SSL session expires in the session cache. Should match the keepalive value.
#
# LINK: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout
# LINK: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslsessioncachetimeout
ssl_session_timeout 60;

# Enable OCSP stapling.
#
# LINK: http://tools.ietf.org/html/rfc4366#section-3.6
# LINK: http://tools.ietf.org/html/rfc6066
ssl_stapling        on;
ssl_stapling_verify on;

# The certificate of our authority for OCSP verification.
ssl_trusted_certificate ssl/ca-bundle.pem;

I also use a custom init.d script to start nginx and directly fetch the OSCP response, this ensures that all clients can validate it. You can find it in one of my repositories.

what do you mean by "hardened" in case of SSL?

which cipher_suites are used in the first hand depends on what cipher_suites are available on your server, then on server_suggestions, then on what the client is able to speak. with those cipher_suites you have ECDHE and DHE configured which is kinda ok when you want to use PFS, but since only TLSv1 ist enabled, i dont think you can use ECDHE anyway, so you'll stick to DHE, which might be used with most browsers. Some very legacy clients (IIRC IE <= 9) might not be able to use PFS, so you'll keep them out with this config.

if you wan to browser-test out the given cipher_suites:

• configure your nginx to use them
• check those ciphers against ssllabs.com
• you can check which ciphers are available on your server with openssl ciphers

the problem with taking cipher_suggestions from 3rd parties:

• if you server cant speak tlsv1.2 you wont be able to use modern PFS-cipher-suites like all those ECDHE - ciphers, but will use the very slow DHE - ciphers
• you should perftest and ssllabs-check your cipher-suites always to see which browsers could get problems.

you might find more infos on nginx + ssl here: Guide to Nginx + SSL + SPDY

some things i dont like about the nginx-config you linked to:

• the cache is also caching "hickups" from upstream
• the ssl-config is not really the best and surely NOT high security

~~~

ssl_protocols SSLv3 TLSv1;
# -> no tlsv1.2/tlsv1.2??? this is NOT high security
# as mentioned in the header

proxy_cache_valid  any 1h;
# REALLY???

~~~

My best guess is that "somewhat compatible" is used as a way of saying "not fully compatible".

That cipher list does not support IE6 as IE6 has no FPS ciphers available to it.

You might also find this article of use.