"Optimal" Web Server SSL Cipher Suite Configuration

Question

Over the last couple of years there have been a number of changes in what would be considered an optimal SSL cipher suite configuration (e.g. the BEAST and CRIME attacks, the weaknesses in RC4)

My question is, what would currently be considered an optimal set of SSL cipher suites to have enabled with the following goals.

• Provide the most secure connection possible, including where possible Perfect Forward Security and avoiding known weaknesses.
• Provide compatibility with a wide range of commonly deployed clients including mobile devices (e.g. Android, iOS, Windows Phone) and desktop OS (including Windows XP/IE6)

Answer 1

The most secure setup doesn't depend only on ciphers, but also on the tls-version used. For openssl, tls 1.1/1.2 is preferred. BEAST and CRIME are attacks on the client and are usually mitigated client-side, but there are server-side mitigations too:

• CRIME: just disable ssl-compression; that's it
• BEAST/Lucky13: just use TLS 1.1, no SSLv3 and no RC4, see Is BEAST Still a Threat? (Ivan Ristic)
• BREACH: works only, if some conditions are met, see breachattack.com; easy and always-working mitigation would be to disbale http-compression (gzip)

For a perfect setup: SSL always impacts performance on a high level, RC4 and other fast cipher-suites might still be ok for static content, esp. when served from your own cdn.

A nice guide to understanding OpenSSL is OpenSSL Cookbook with detailed explanations also on PFS, cipher-suites, tls-version etc. pp. there are 2 blogposts that explains PFS and practical setup:

• SSL Labs: Deploying Forward Secrecy
• Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

cipher-suites-suggestions to enable PFS also on older clients:

# apache
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

# nginx

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

For a detailed nginx/ssl-manual I'd like to direct you to this Guide to Nginx + SSL + SPDY.

Answer 2

In the year since this answer was written, Mozilla's guide has been updated regularly. All of my reservations below have been taken into account, and I recommend the guide wholeheartedly.

---

I recommend that you read Mozilla's Server Side TLS guide. It's comprehensive, and they are especially careful about compatibility with old clients, sometimes to the detriment of security. (After all, IE 6 users deserve to be able to download Firefox.) I would like to emphasize several things:

• Supporting Windows XP/IE 6 is not optimal. I suggest you drop it if possible. It requires SSL 3.0, which leaves decent clients open to downgrade attacks. Edit: Anti-weakpasswords reports in the comments above that IE 6 can support TLS 1.0. I have no idea what percentage of IE 6 clients support it or have it enabled, though.

• Supporting XP/IE 8 isn't bad. It supports TLS 1.0, though its best cipher suite is DES-CBC3-SHA and it doesn't support perfect forward secrecy or SNI. (Its second-best cipher suites are RC4-SHA and RC4-MD5. 3DES is very slow, but RC4 has security issues. Avoid it if possible.)

• 2048-bit Diffie-Hellman parameters are best from a security point of view, but Java 6 only supports 1024-bit parameters. Common 1024-bit parameters may or may not have been broken by NSA supercomputers, but 1024-bit DH is otherwise more or less safe for now. You might need to use it. (Java 7 supports ECDHE, bypassing the whole issue of DHE parameter size.)

Mozilla's primary cipher suite list includes RC4. As above, I recommend the list from the RC4 weaknesses section that uses 3DES instead.

Mozilla's configuration examples enable SSL 3.0. As I said, I would discourage that.

Mozilla's configuration examples mainly recommend 2048-bit DH parameters, but they also give 1024 as an option.

Answer 3

Of course, the first step is to keep OpenSSL (or the library you use) up to date.

But as new vulnerabilities are discovered and browsers are upgraded, the answers here can (will) become outdated. I'd suggest you rely on the Mozilla SSL Configuration Generator to check which configuration you should use.

Answer 4

The 'Optimal' SSL Cipher that you configure on your webserver would depend on your customer requirements. In many cases, that would be a factor in the choice of the protocol and cipher suites. Not sure if that is the case for you.

You could configure the best security possible -- only support TLS 1.2 protocol, only ciphers with Perfect Forward Security (PFS) and only AES 256. Within PFS, you may support only the elliptic curve variant ECDHE. You may choose the newer secure GCM ciphers that provide authenticated-encryption and provide very good performance (with AES-NI instruction). But if your most important customer uses IE8 on Windows 7 and you cannot convince them to upgrade the browser, then they won't be able use your service and you will lose a customer.

ssllabs.com provides a web service to scan your site and give ratings like A+, A, B etc. The rating is based on numerical scores (max 100) received for 4 parameters --- Certificate, Protocol Support, Key Exchange and cipher strength. They give higher marks if Perfect Forward Secrecy (PFS), Strict Transport Security (HSTS), to name a few, are supported.

Note that the score may change over a period of time as browsers and servers get patched, new weaknesses emerge, new exploits are discovered etc. Earlier, ssllabs gave a lower rating to sites that did not implement server-side mitigations for the BEAST attack, but they have stopped doing that as they consider it mitigated on the client side (except for the laggard Apple), but more so because the mitigation involved enforcing RC4 (for protocols TLS 1.0 or lower) and it turns out that RC4 is much weaker than previously thought.

You can go to the ssl labs site, enter your url and get the score.

The SSL labs report includes a section on Handshake simulation where it shows a bunch of clients (browsers, Java, openssl) and what protocols, cipher suites, key sizes will be negotiated with your server. If negotiation is not possible it will show "Protocol or cipher suite mismatch" in red. You can lookup the Handshake simulation for the configuration used by your important customers. For e.g., you may see the entry

IE 8-10/Win7, TLS 1.0, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, FS 256

But say you tighten your server's ssl configuration to support only TLS 1.2, then this row will read

IE 8-10/Win7, Protocol or cipher suite mismatch, Fail

But, as your customers migrate/update/upgrade, you can tighten the security with the goal of TLS 1.2 only, PFS only and 256 bits only

Another important info the report provides is whether the cipher suites are in server-preferred order or not. In the former case, the order of ciphers listed in the server configuration will be honored --- so you put the preferred cipher suites first. The first cipher in the list that both server and client can use will be chosen. If you use Apache, you can enable this with the directive "SSLHonorCipherOrder on". For nginx, the directive is "ssl_prefer_server_ciphers on;"