Web Server’s SSL Ciphers

Dis­claimer: I’m up­dat­ing this post con­tin­u­ally in order to rep­re­sent what I con­sider the best prac­tice in the mo­ment – there are way too many dan­ger­ously out­dated ar­ti­cles about TLS-de­ploy­ment out there al­ready.

There­fore it may be a good idea to check back from time to time be­cause the crypto land­scape is chang­ing pretty quickly at the mo­ment. You can fol­low me on Twit­ter to get no­ti­fied about note­wor­thy changes.

If you find any fac­tual prob­lems, please reach out to me im­me­di­ately and I will fix it ASAP.

Rationale

If you con­fig­ure a web server’s SSL con­fig­u­ra­tion, you have pri­mar­ily to take care of three things:

1. disable SSL 2.0, and – if you can afford it – SSL 3.0 (Internet Explorer 6 is the last remaining reason to keep it around; you can’t have elliptic curve crypto with SSL 3.0 and downgrade attacks exist),
2. disable TLS 1.0 compression (CRIME),
3. disable weak ciphers (DES, RC4), prefer modern ciphers (AES), modes (GCM), and protocols (TLS 1.2).

You should also put ef­fort into mit­i­gat­ing BREACH. That’s out of scope here though as it’s largely ap­pli­ca­tion-de­pen­dent.

Software and Versions

On the server side, you should up­date your OpenSSL to 1.0.0+ so you can sup­port TLS 1.2, GCM, and ECDH as soon as pos­si­ble. For­tu­nately that’s al­ready the case in the cur­rent Ubuntu LTS.

On the client side, the browser ven­dors are start­ing to catch up. As of now, Chrome 30, In­ter­net Ex­plorer 11 on Win­dows 8, Sa­fari 7 on OS X 10.9, and Fire­fox 26 sup­port TLS 1.2 (but no GCM, Chrome 32 is going to be the first one to sup­port that). Fire­fox also has TLS 1.2 dis­abled by de­fault which changed re­cently in Au­rora.

RC4

There used to be a bul­let point sug­gest­ing to use RC4 to avoid BEASTand Lucky Thir­teen. And iron­i­cally, that used to be the orig­i­nal rea­son for this ar­ti­cle: when Lucky Thir­teen came out, the word in the streets was: “use RC4 to mit­i­gate” and every­one was like “how!?”.

Un­for­tu­nately shortly there­after, RC4 was bro­ken in a way that makes de­ploy­ing TLS with it nowa­days a risk. While BEAST et al re­quire an ac­tive at­tack on the browser of the vic­tim, pas­sive at­tacks on RC4 ci­pher­text are get­ting stronger every day. In other words: it’s pos­si­ble that it will be­come fea­si­ble to de­crypt in­ter­cepted RC4 traf­fic even­tu­ally. Mi­crosoft even is­sued a se­cu­rity ad­vi­sory that rec­om­mends to dis­able RC4.

The String

Until re­cently, Qualys pre­ferred RC4 over CBC-mode ci­phers and I gave you two ci­pher strings to choose from: one that gave you an “A” but used RC4 and one that gave you a “B” but was ac­tu­ally se­cure. Since they fi­nally changed their mind – and as of Sa­fari 7 there’s no main­stream browser left that is sus­cep­ti­ble to BEAST – I can jump di­rectly to the se­cure one:

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

You can test it against your OpenSSL in­stal­la­tion using

openssl ciphers -v 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'

to see what’s sup­ported.

You’ll get:

• Best possible encryption in all browsers.
• Perfect forward secrecy; if your web server, your OpenSSL, and theirbrowser support it.
• It doesn’t offer RC4 even as a fallback. Although its inclusion at the endof the cipher string shouldn’t matter, active downgrade attacks on SSL/TLS exist and having RC4 as part of the the cipher string you potentially expose all of your users to it. Even IE 6 does 3DES just fine.

The string also prefers AES-256 over AES-128 (ex­cept for GCM which is pre­ferred over every­thing else). It does so mostly for li­a­bil­ity rea­sons be­cause cus­tomers may in­sist on it for bogus rea­sons.

How­ever quoth a cryp­tog­ra­pher:

AES-128 isn’t re­ally worse than AES-any­thin­gelse, at least not in ways you care about

So if AES-128 is fine for you, feel free to add an ‘:!AES256’ to the end of the ci­pher string to keep your ci­pher suite shorter which will also ex­pe­dite your TLS hand­shakes.

Apache

1
2
3

SSLProtocol ALL -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

This works on both Apache 2.2 and 2.4. If your OpenSSL doesn’t sup­port the pre­ferred mod­ern ci­phers (like the still com­mon 0.9.8), it will fall back grace­fully but your con­fig­u­ra­tion is ready for the fu­ture.

Please note: you need Apache 2.4 for ECDH and ECDSA. You can cir­cum­vent that lim­i­ta­tion by putting an SSL proxy like stud or even nginx in front of it and let Apache serve only plain HTTP.

TLS com­pres­sion is a bit more com­pli­cated: as of Apache 2.2.23, it’s not pos­si­ble to switch it off in­side of Apache. For Apache 2.2.24+ and 2.4.3+, you can switch it off using:

1

SSLCompression Off

Cur­rently the de­fault is On, but that changed from 2.4.4 on.

The good news for Ubuntu ad­mins is that Ubuntu has back portedthat op­tion into their 2.2 pack­ages – and set it to off by de­fault – so you should be fine. The so­lu­tion on Red Hat based OS (RHEL, Fe­dora, Cen­tOS, Sci­en­tific Linux…) is set­ting an en­vi­ron­ment vari­able in­side of your Apache startup script:

1

export OPENSSL_NO_DEFAULT_ZLIB=1

nginx

1
2
3

ssl_prefer_server_ciphers On;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

SSL 2.0 is off and the best pro­to­cols on by de­fault. How­ever it may be that you have some ar­ti­fact from pre-TLS 1.2 times lurk­ing some­where in your con­fig so it’s bet­ter to be ex­plicit.

TLS com­pres­sion de­pends on the ver­sion of nginx and the ver­sion of OpenSSL. If OpenSSL 1.0.0 or later is in­stalled, any­thing after nginx 1.0.9 and 1.1.6 is fine. If an older OpenSSL is in­stalled, you’ll need at least nginx 1.2.2 or 1.3.2.

For more de­tails, have a look at this server­fault an­swer.

TL;DR on TLS com­pres­sion & nginx: if you’re using Ubuntu Pre­cise (i.e. the cur­rent LTS re­lease) you’re fine (OpenSSL 1.0.1/nginx 1.1.19).

Bonus Points

Qualys up­dated their re­quire­ments on 2014-01-21 and the ci­pher suites here are still “A”–ma­te­r­ial. If you want an “A+” though, you’ll need to add HSTS head­ers too, which is out of scope for this ar­ti­cle but the linked Wikipedia ar­ti­cle will get you started.

Finally

Make sure to test your server af­ter­wards!

If you want to learn more about de­ploy­ing SSL/TLS, Qualys’s SSL/TLS De­ploy­ment Best Prac­tices are a de­cent primer.

For in­ves­ti­gat­ing the SSL/TLS be­hav­ior of your browser, How’s My SSL?will give you all the de­tails you need.

The (Near) Future

2013 has gal­va­nized the whole in­dus­try. This is a good thing. In 2012 barely any­one lost a thought about con­fig­ur­ing their TLS ci­phers, how many bits their cer­tifi­cates had, or even for­ward se­crecy. That made it way too easy for the bad folks. Nowa­days, peo­ple are ques­tion­ing their own prac­tices, open source pro­jects work on en­hanc­ing their TLS sup­port, and the pub­lic started to lis­ten to cryp­tog­ra­phers again in­stead of dis­count­ing them as crazy tin­foil crowd.

Good things are shap­ing on the hori­zon and Google’s Adam Lan­g­leygiven the power of hav­ing con­trol over both servers and the most pop­u­lar browser is press­ing ahead. Their servers widely sup­port TLS 1.2 with AES-GCM. Chrome has the best TLS sup­port al­ready. Ad­di­tion­ally, its Ca­nary re­leases now have grown sup­port for ChaCha20 which is an ex­tremely fast yet se­cure stream ci­pher by Dan Bern­stein and Poly1305a great MAC of the same pedi­gree.

Now if peo­ple just stopped using old browsers and we could roll outSNI and manda­tory TLS 1.2.