Choosing TLS / SSL cipher suites - What considerations are there?

Question

Most of the advice on choosing cipher suites I find tends to be one of these forms:

• Here's a string to paste into your application, or
• Here's a list of 30,000-foot generic criteria to use ("favor stronger ciphers") (gee thanks)

The former tend to be outdated quickly and don't really educate the reader on why those ciphers are ordered in that way. The latter tend to be so open-ended as to be useless.

Instead, what I'd like to know is:

• Is there a generally accepted criteria for determining which ciphers to support, and in what order? Most importantly, why are those criteria important?
• Presumably, some ciphers are tougher to crack than others. Some are faster than others. Some may have other perks or considerations I don't even know about. Are there resources for figuring this out without getting a graduate degree in cryptanalysis?

Answer 1

Is there a generally accepted criteria for determining which ciphers to support, and in what order? Most importantly, why are those criteria important?

Case 1: You control both ends of the communication.

1.a. (sorry to repeat part of your question but you have no choice than) Use the highest suite components which are supported by your chosen software.
1.b. If that does not satisfy your needs then create your own implementation of a suite component which is not yet implemented but is published and peer-reviewed in academic environment.
1.c. If that still does not meet your needs, invent your new algorithm and wait for it to be peer-reviewed before implementing it.

Case 2.1: You don't control the peer, but you are in need of information exchange under his conditions (ex. you are visiting a website, let's say your bank online account)

Accept the highest combination the peer is offering. Lookup online each algorithm details/weaknesses and evaluate what are your loses if/when your communication is compromised. Constantly monitor changes in peers offering.

If you find these loses unacceptable then find alternate means of exchanging information (ex. go to the bank office instead)

Case 2.2: You don't control the peer, but you wish to reach an intended audience (ex. you are selling openvpn accounts)

Constantly monitor progress in cryptography and always offer the highest suites available.
Constantly monitor existing suite for weakness (ex. subscribe to alerts regarding the software you use and the algorithms that are implemented) and when a new weakness is published, evaluate how is that impacting the numbers of intended audience (assuming that you will drop the vulnerable suites knowing that by doing this so will potentially reduce audience)

To summarize all three cases, the strongest criteria is:
In what degree a leak or altering of information I exchange is affecting me, my friends, my business or my business partner(s) and how much do I care about it?

Presumably, some ciphers are tougher to crack than others. Some are faster than others. Some may have other perks or considerations I don't even know about. Are there resources for figuring this out without getting a graduate degree in cryptanalysis?

Just stay up to date with current official cipher suites list and always choose the highest available. Keep an eye for example on what NSA recommends for their internal use. An expanded view of @bonsaiviking's answer linked in the first comment of your question is detailed on Google's Online Security Blog

Answer 2

@costin offers good advice in his comment.

This is a deep topic where any "quick answer" will, by necessity, leave out important details for your particular use case. That's why you see lots of advice of the forms you cite (e.g. too general "use strong ciphers," or overly specific "paste this string" with no explanations).

That said, I'll offer my own incomplete answer from a fairly basic, practical standpoint. ;-)

For public web apps, where you don't control the end user connection, disable SSL 3.0 and lower - see recent POODLE attack mitigation see POODLE PDF .

There are some academic weaknesses in TLS 1.0 as well, but it may be the best some browsers can handle. Still, most of the recommends say to go to later versions of TLS if you can.

A while back, RC4 was recommended as a mitigation for the BEAST attack, but it has it's own known weaknesses, and that advice is now also considered out of date.

A whole class of "oracle padding attacks" have been launched against various Chained-Block-Cipher (CBC) suites, so in general those are out of favor as well.

RFC 4492 defines Elliptic Curve Ciphers (ECC) and TLS can use Elliptic Curve Diffie-Hellman (ECDH) which seems to be gaining popularity.

Yes, there are speed/strength/memory/performance trade-offs with ciphers which you may have to deal with if you run a high-volume web application for an enterprise, but for many single-server websites, those kind of trade-offs don't really enter in to it.

Practical advice: A good starting point for a simple health check is to analyze your server with SSLlabs and fix anything they mark you down for. No, it isn't perfect, nor will it replace good knowledge of the security trade-offs you may be asked to make, but it will make you more secure (in a practical sense) than most of the other sites out there.