== 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 SSLForwardSecrecy]]). 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 http://www.openssl.org/docs/apps/ciphers.html]] 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 http://www.rtfm.com/ssldump/]] 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 http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29]]. 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 http://www.iana.org/assignments/tls-parameters/tls-parameters.txt]], 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.)