Hacker News Reader

Comment by wolf550e | Hacker News Reader

Unless I missed it, article does not say "use https://www.ssllabs.com/ssltest/ to test your setup", which I think is very useful advice.

Also, you might consider configuring your server to only support cipher suites that will be supported by TLS 1.3 [0][1] and let old clients get errors. If you need security, don't use the obsolete stuff the experts don't trust anymore.

0 - https://tlswg.github.io/tls13-spec/#rfc.section.1.2

1 - This means use only (ECDHE|DHE)-(RSA|ECDSA)-AES128-GCM-SHA256 and (ECDHE|DHE)-(RSA|ECDSA)-AES256-GCM-SHA384. No key exchanges that don't provide forward secrecy, no RC4, no CBC mode, no MD5, no SHA1.

View on HN

You can add (ECDHE|DHE)-(RSA|ECDSA)-CHACHA20-POLY1305 to that too (pretty soon).

If you don't care about OCSP stapling, you can use BoringSSL and get that cipher today!

ex: https://time.ian.sh

And LibreSSL also has support for ChaCha20.

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.

0 - https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...

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

[1]: https://github.com/cloudflare/sslconfig/blob/master/conf

That's a very nice idea.

Of course, you sound like exactly the kind of sysadmin I'm not concerned about ;-)

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.

Reply on news.ycombinator.com