Good SSL for your website is absurdly difficult in practice
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
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.)