Good SSL for your website is absurdly difficult in practice

September 7, 2013

It all started with a tweet by Thomas Ptacek which I replied to. That inspired me to take another run at configuring my personal site so that it had a top-grade SSL/TLS configuration.

I failed. Which leads to this rant. In order to have good TLS on your website, here is what you need (in the abstract):

  • You need to know what the current state of the art is in recommended TLS settings and attacks, both for things to actively support (such as perfect forward secrecy) and things to avoid (RC4, TLS compression, and so on). All by itself this is a minefield of outdated or contradictory advice.

  • Your system's TLS libraries must support everything you want to do (and sometimes your application software too). You also need to know how to find out whether they do. This is far from guaranteed; on Unix systems, your OpenSSL library may be too old or compiled without patent-encumbered technology like elliptic curve cryptography. If good TLS settings require things your normal libraries don't have you may have to build your own.

    (Did you know that Fedora compiles OpenSSL without ECC? I didn't until I started reading deeply in this. Oh, and you may have to rebuild not just OpenSSL but also applications that depend on it, per this bug comment.)

  • You must successfully translate those abstract good TLS settings into actual concrete settings for your TLS libraries and application. This primarily means controlling cipher choices through cipher names. You also need to deal with the fact that different clients support different ciphers so your job is not just to specify a few really good ciphers but to come up with a cipher ordering that prioritizes the good stuff, avoids the bad stuff, works as best as possible for as many clients as possible, and probably doesn't leave any clients in the cold.

    Oh, and the available documentation for your TLS library is probably not very good and may not be complete. You also get to go through a three way translation process between full cipher names as reported in, eg, protocol decodes of actual client traffic, how you name and configure various sorts of ciphers in your TLS library, and the names that were used for ciphers in the abstract good TLS settings you've read up on.

    Unless you're a real expert there is a lot of black magic and superstition in this process. You're taking guesses and hoping that they work right, which brings us to the next issue.

  • Having come up with what you think is a good configuration, you need to test it to see if it does what you think it does and gives clients good results. In the process you may have to make decisions about client support; for example, is it okay if IE 6 on Windows XP probably can't connect to you? Is the testing you're doing really covering the smartphone and tablet world?

    There are testing sites but their results aren't necessarily complete and may require interpretation.

In the current environment you can apparently look forward to doing all of this all over again in six months when a new vulnerability gets discovered in another part of the TLS world.

Of course if you don't care about having top grade TLS support on your website, life is much easier; you can just accept the TLS defaults on your software. I'm not surprised that lots of people do just this because doing significantly better is a lot of work.

(You can also try following recipes that you found on the Internet. This may or may not actually work for you. If it doesn't work it may be because of something obscure in your specific environment, as it may have been for me until I discovered you have to recompile not just OpenSSL but lighttpd too in the process of writing this entry.)

Written on 07 September 2013.
« Making switch configuration changes is not as easy as it looks
Why wiring things up physically instead of virtually is better for us »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 7 00:49:59 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.