This raises an issue that has been troubling me recently. There has been an explosion in guides that tell you how to secure your TLS installation, and virtually all of them hard code a cipher list, which I fear won't get refreshed as better ciphers come out. I've also seen this with recent instructions to disable SSLv3, which whitelist TLSv1, TLSv1.1, and TLSv1.2, instead of just blacklisting SSLv2 and SSLv3.
To avoid a situation where future security improvements are held back by crufty configuration that was added in a well-intended effort to improve present-day security, I think we should be encouraging blacklists instead; the OpenSSL cipher list spec actually supports blacklisting.
I have a weekly cron that checks my nginx cipher list against Cloudflare's[1]. They're pretty much always first to deploy on new ciphers and they know what they're doing. And it, for instance, picked up on and reminded me to change all ~14 of my SSL configs in response to POODLE
Sadly, I've come to the conclusion that it's no longer possible to build future-proof cipher suite configuration in a generic way. There are simply too many rules to follow, if you want to get everything right. I spent lots of time trying and in the end gave up.
Now I give my recommendations as an ordered list of suites. It's easy to set up, does exactly what you want and, as a bonus, everyone can look at the list and understand which suites exactly are configured.
That said, I'd like to see good default configurations in libraries and server programs, which can be updated via patches as needed. Then we wouldn't really need to bother with cipher suite configuration at all.
When the standard adds the feature that enables using AES GCM when both sides have an implementation that is fast and resistant to timing attacks and falls back to chacha20-poly1305 when they don't [0], and the chacha20-poly1305 cipher suite itself is standardized, then we should all add that.
