SSL/TLS and ciphers vulnerability

Question

I've been off the list for a bit, getting ducks in a row here and everything.

I noticed a number of posts about SSL & TLS security settings lately and I wanted to point out that maintaining your SSL configurations is an on-going processes.

New exploits are discovered and released quite often, and often the fault lies with a cipher and not necessarily an overall SSL/TLS protocol.

So using a cipher list like "all except RC4" is probably not sufficient anymore. And what is secure may depend completely on the SSL/TLS software you use, be it OpenSSL or Java's built in SSL libraries.

For example, with OpenSSL, you should be using 1.0.1t or higher, and even then only TLS1.2 with a handful of ciphers. I'm not sure what the recommended options for java's libraries are at the moment. A really good, free tool is Qualys' SSL Labs server test tool located at: https://www.ssllabs.com/ssltest/ Run that against your implementation and follow its recommendations.

Of course, at the end of the day, it will be up to you and your firm to decide what risks you are willing to take with your SSL communications and whether or not you need to support insecure browsers, i.e. browsers that cannot negotiate up to the most secure protocol and ciphers.

Comments

Working for a corporation that has strict ssl and security requirements.. There is no way to use the tools you suggested, since the tomcat URLs are not exposed.

Answer 1

Few thoughts:

1. Since Tomcat can take OpenSSL-style cipher suites configuration, is there a way to ask Tomcat to take an OpenSSL 'ciphers' specification and have it emit the JSSE equivalent? I know Tomcat does this internally, but can it dump the configuration for debugging purposes?

2. The OpenSSL ciphers specs on the "Ciphers" page above only includes "HIGH" ciphers which is appropriate for today's safety, but it doesn't prioritize them in any particular way. This may be the default for OpenSSL, but I typically prioritize ECDHE and ECDH ciphers before the other ones in the HIGH category.

3. There's usually no reason to include the "PSK" (pre-shared key) ciphers in your server's cipher spec, so I always disable those as well.

4. It's fairly important to enable "server-order" cipher suite selection, so that the server's preferences are used over the client's preferences, in case you have a lay client who would choose a trivial cipher if it were available. This is, for example, how older versions of MSIE behave: they REALLY prefer to use cipher suites using RC4 even if higher-grade ones are available. Of course, you should really disable cipher suites you aren't willing to use, but sometimes you just HAVE to include some really bad ciphers in the list in order to support super-old clients.

5. Many people don't know about the "Unlimited Strength Policy Files". I've been thinking that we might want to issue an INFO message at startup if TLS/JSSE is in use and the "Unlimited Strength Policy Files" aren't available. This may encourage more people to install them. Unfortunately, I don't know if a way to install those files without modifying the JRE being used to launch the JVM. If anyone knows how they can be installed just for one application (Tomcat), it would be nice to provide a guide for how to do that.

6. Qualys has a tool called ssllabs-scan available on GitHub: https://github.com/ssllabs/ssllabs-scan/
   I haven't read-through the code yet, but I suspect it's a copy of the whole scanner and doesn't "phone home" (except maybe to grab the latest configuration and scoring rules). This may make it possible to scan some of those internal servers that aren't facing the public Internet (and therefore can't be scanned directly using ssllabs web-based tool). It may also speed-up the scanning of a site, since their web-based tool is throttled to avoid using it as a DOS tool.
   The existence of the ssllabs-scan tool means it's also possible to set-up automated periodic scanning of your own site(s). If you expect to get an "A" rating and one day you aren't "A" quality any more, you should get an alarm without having to remember to manually-run the web-based tool when you get around to doing it.