# “Optimal” Web Server SSL Cipher Suite Configuration

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)
• Supporting IE 6/XP is not optimal. It requires SSL 3.0, no SNI, no forward secrecy, and its best cipher suite is DES-CBC3-SHA (or RC4-SHA or RC4-MD5, but those are worse). If you can settle for IE *8*/XP, that would be better. It has most of the issues above, but supports TLS 1.0, reducing the risk of downgrade attacks against other clients. – Matt Nordhoff Feb 18 '14 at 1:55
• Matt, IE6 does support TLS 1.0 with a simple checkbox under Advanced options (or, as I recall, a patch from several years ago that checks the checkbox), see How to enable SSL v3 & TLS v1 for Internet Explorer – Anti-weakpasswords Feb 18 '14 at 3:28
• @Anti-weakpasswords Did not know! Interesting. Maybe someone needs to tell Qualys, then. How many IE 6 users actually have that box ticked, though? – Matt Nordhoff Feb 18 '14 at 4:00
• @MattNordhoff I believe most of them had it checked by a 2007 vintage Windows Update patch, but I can no longer find that reference. However, I did find a Microsoft answers reference to the TLS 1.0 option in IE6 where PA Bear says "If you use Microsoft Internet Explorer 6 or higher [snip] go to: Tools > Internet Options > Advanced Tab, scroll down to the Security section and ensure that the "Use TLS 1.0" option is checked, then click OK." – Anti-weakpasswords Feb 23 '14 at 7:17
• Qualys (SSL Labs) shows which will work with the default out of the box settings, not which can be made to work. If you test a site that has all SSL and TLS 1.0 disabled it shows no version of IE other than 11 working, but most of the IE configurations can be made to work with TLS 1.1 or even 1.2 by checking a tick box in the settings. – Rod MacPherson May 7 '15 at 16:58

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:

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.

• See also NIST SP 800-52 Rev.1 Draft, which has quite a lot of discussion on cipher suite choices. – Anti-weakpasswords Feb 18 '14 at 0:08
• RC4 is broken, replace it with 3DES which is slow but secure. Note that clients that don't support AES also don't support anything but RSA for both auth and kex. AES-CBC-HMAC-SHA256 is no more secure than AES-CBC-HMAC-SHA1, no need to prioritize it. But you should prioritize GCM above CBC. You don't need SEED or CAMELLIA. Thus my recommendation is: -ALL EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EDH+aRSA+AESGCM EECDH+ECDSA+AES EECDH+aRSA+AES EDH+aRSA+AES RSA+3DES – Z.T. May 7 '15 at 19:35

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. 1024-bit parameters are also secure, unless your adversaries include supercomputers decades in the future. You might need to use them instead. (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.

• +1 for pointing out the weak parts of mozillas suggestions – that guy from over there Feb 18 '14 at 11:48
• Mozilla have since this post change the page to create 3 security levels, depending of your browser version requirement: Modern, Intermediate, old/legacy – higuita Oct 16 '14 at 16:31

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.

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

## protected by Rory Alsop♦Feb 3 '15 at 9:06

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).