Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I found some hardened SSL settings in github.com/ioerror/duraconf.

Here is the header from the config:

This is an example of a high security, somewhat compatible SSLv3 and TLSv1 enabled HTTPS proxy server. The server only allows modes that provide perfect forward secrecy; no other modes are offered. Anonymous cipher modes are disabled. This configuation does not include the HSTS header to ensure that users do not accidentally connect to an insecure HTTP service after their first visit.

It only supports strong ciphers in PFS mode:

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

# Only strong ciphers in PFS mode
ssl_ciphers ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA;
ssl_protocols SSLv3 TLSv1;

If we were to use these settings on our website, what does "somewhat compatible" mean? For example, would IE6 still be able to connect?

share|improve this question
    
This is a pretty broad question, IMO. However, you should be pretty compatible with that, though I've never seen much need to change it from the default ciphers of ssl_ciphers HIGH:!aNULL:!MD5; explained in the Nginx Wiki. Here's a good browser compatibility list for TLS. Here's a compatibility list for Windows. –  nojak Nov 9 '13 at 0:15
    
@nojak You've never heard of BEAST? CRIME? Forward secrecy? –  Michael Hampton Nov 10 '13 at 17:13
    
@MichaelHampton Apparently I need to look into those... –  nojak Nov 11 '13 at 17:08
add comment

3 Answers

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???

~~~

share|improve this answer
    
ECDHE suites are allowed in SSLv3 and later. Suites that use SHA2 (SHA256 or SHA384) and suites that use GCM can't be used in TLSv1.1 and earlier –  Hubert Kario Feb 11 at 22:41
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.