Wandering Thoughts archives

SSL/TLS cipher names (aka 'cipher suites') and what goes into them

Since I just researched this for the Nth time, it is clearly time that I write it down once and for all. I need to start with a high speed overview of TLS (for my own memory if nothing else).

(All of this is annoyingly confusing and complex.)

TLS conversations themselves are encrypted by some variety of symmetric stream cipher and have some sort of 'message authentication' aka a signature. The key for the stream cipher is arranged during the initial TLS handshake using one of a variety of key exchange protocols (this is what matters for things like forward secrecy). The initial TLS handshake also 'authenticates' the server and optionally the client by verifying their certificate private keys and signatures with some protocol.

TLS helpfully bundles together all four of these separate functions in a single 'cipher name' or 'cipher suite' (really a 16-bit unsigned number), which gives us a profusion of confusing and relatively opaque names. For bonus points there are several different ways of writing these, sometimes going into more or less detail about things involved. And because all of this naming was done by humans, there are exceptions to everything.

Time for some examples. At the level of OpenSSL configuration and OpenSSL commands, you get names like DHE-RSA-AES256-SHA. This means DHE for key exchange, RSA for server certificate authentication, 256-bit key AES for the stream cipher, and SHA for the message authentication. In TLS configuration you can often abbreviate cipher names (sometimes to be more general, for example to say 'all ciphers that use SHA'); see the OpenSSL 'ciphers' manpage for more detail.

(Note that some of the OpenSSL names violate this four-element pattern in various confusing ways.)

At a somewhat deeper level, one often printed by protocol decoders and used internally by OpenSSL, you get more detailed names like TLS_DHE_RSA_WITH_AES_256_CBC_SHA. This adds two extra pieces of information; first, this cipher suite originates with one of the TLS standards, and second, it uses AES256 in CBC mode. Like the simpler names, there are any number of exceptions from the 'standard' format for these complex names.

Some cipher suite names don't explicitly mention the key exchange protocol. I believe this means that the key exchange is done as part of the certificate signature verification, which will usually be with RSA. Some OpenSSL names also omit the signature verification protocol, eg 'RC4-SHA', in which case I believe it is always RSA. The more detailed names usually keep the 'RSA' bit in that case.

(People add new cipher suites all the time. IANA has an authoritative list of what number is what cipher suite, in case some tool you're dealing with doesn't know about a particular cipher suite and just prints raw numbers.)

Note that SSL/TLS is in general full of cipher suites that are terrible ideas and that you don't want to touch with the proverbial ten foot pole. Some of them are present for historical compatibility, some of them are present because good ideas turned out not to be, some of them are present because people forced stupid ideas to be included, and some are a combination of several of these. Some but not all of these no longer used in practice. Some surprisingly modern clients are still willing to use ancient and frankly horrifying cipher suites if the server really wants them to.

(I have seen a recent version of IE on Windows 7 offer to use TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, which is a 40-bit DES cipher that was obsolete when it was introduced and dangerously broken at least a decade ago.)

What good cryptography error messages need to include

Suppose that you have a system that involves cryptography and at some point your cryptography indicates that there is a problem, one where something isn't verifying properly. Many programs fumble what happens next in a way that significantly degrades their security; they give people bad error messages, ones that make it hard for people to understand what's wrong.

Crypto error messages are very important because crypto error messages are your one chance to convince people not to go on anyways. People really want to what they were planning to do, so their default action is to override your warnings or errors and go on anyways (in whatever way that that takes). If there is a real problem (as opposed to a false alert) you desperately want people to stop, so you desperately want to convince them that there is a problem.

Generic error messages do not do this. Cryptic error messages do not do this. What both communicate to most people is nothing more than 'something went wrong in the magic black box' and that is not going to stop people from going on.

So my view is that a good crypto error message needs to include four things (at least). It needs to tell me exactly what is wrong, what it happened to, what it might mean, and what the minimal workaround is. As much as possible it should cover all of this in plain language because most people will not understand technical jargon. A good error message should also be comprehensive, in that the program should check everything it can instead of just stopping at the first error.

(It goes without saying that a good error message should also be accurate. Inaccurate error messages are a great way of training people to ignore them entirely.)

Although it's tempting to say that the goal of a crypto error message is to give people enough information that they can make an informed decision, that's not really it. The real goal is to give people enough information to convince them that you're right and something really is wrong. Allowing them to make an informed decision is secondary, although important in reality (because in reality it's probably more likely that you're wrong). If people override your warning, you want to have given them enough information so that they can confidently say why you're wrong.

(Well, so that people who care and pay attention can confidently say so. I'm a realistic idealist about this.)

Systems with cryptography should always have minimal workarounds

Here is something that I've come to firmly believe: if you have software that uses cryptography, your software should either absolutely refuse to work if the cryptography rejects something or it should have a minimal workaround for the failure; the worst thing you can do is have a nice 'turn off all crypto' option. I wrote one version of why in this entry about a Yum cryptography failure, but I want to repeat it generally because this is a very important point for usable real-world security.

In general, this follows directly from observed user behavior and from the fact that people mostly don't care about security. When your system tells people that there is a cryptography problem, real people have two choices; they can give up entirely or they can tell your system to go on anyways. Very few people will chose the first option because very few people are going to give up on what they wanted to do. If the only option you give people for going on is totally disabling your cryptography, that is the option that people are going to use. This is a terrible result. You have just forced people to throw away all of your protection, even (or especially) in a potentially dangerous situation (after all, your cryptography protections already triggered once). A much better option is a minimal one, one that turns off or overrides only enough cryptography to sidestep the specific current problem.

In short: if your cryptography rejects something, people are going to go on anyways if it's at all possible. You want them to go on in a way that does as little harm as possible.

Browsers are a decently good example of this. When you connect to something with an invalid SSL certificate browsers don't force you to completely turn off SSL certificate verification; instead they let you override it just for the particular site. Your system should provide something similar.

Note that there are hard problems when dealing with a cluster or a cascade of errors. If your system is processing a bunch of independent objects, for example, you may not want to stop at the first crypto error but instead check everything and then summarize the results. This gives you a chance to work out the real minimal workaround (and also to notice if this seems to be a really big problem), because it doesn't take more than a few rounds with the user experiencing successive failures before they'll reach for the big red 'turn off all crypto' option.