SSL Cipher Suites: The Ultimate Guide

A deep look at the algorithms that facilitate SSL and TLS

For most people, the topic of mathematical underpinnings of digital encryption is one that’s entirely appropriate for cryptographers and nerds. Incidentally, there’s a lot of overlap on that Venn diagram:

There are, however, times when having at least a basic working knowledge of SSL cipher suites is exceedingly useful. Specifically, when you’re making public key infrastructure (PKI) choices for your organization. A cipher suite is a collection of algorithms that work collaboratively to facilitate a specific function — in our case, we’re talking about the ciphers that facilitate secure sockets layer/transport layer security (SSL/TLS).

Terminology: SSL Cipher vs TLS Cipher Suites

It’s important to note that in IT and information security, we’re creatures of habit and are slow to change. SSL and TLS are terms that are frequently used interchangeably (although, yes, we know that TLS is the successor of SSL). So, throughout this article, we’ll periodically refer to TLS cipher suites as SSL cipher suites (with the exception of when we refer to specific versions of TLS such as TLS 1.2 or TLS 1.3, which we’ll get to in a moment).

There are effectively two sets of approved SSL/TLS cipher suites as of summer 2018 when TLS 1.3 was officially finalized. TLS 1.3 has streamlined a lot of the handshake process — where these ciphers are negotiated — which means it uses shorter cipher suites than TLS 1.2.

This is going to cause a lot of organizations to rethink their implementations once 1.3 finally becomes fully proliferated, but in the meantime, it will be useful to discuss both TLS 1.2 and TLS 1.3 ciphers.

TLS 1.2 Ciphers

TLS 1.2 cipher suites contain four individual ciphers that all work together during the handshake. A TLS/SSL cipher suite looks like this:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

That includes:

PROTOCOL_KEY EXCHANGE ALGORITHM_DIGITAL SIGNATURE ALGORITHM_BULK ENCRYPTION ALGORITHM_HASHING ALGORITHM

We can go ahead and toss out the protocol, it’s always TLS. SSL 2.0 and SSL 3.0 have been deprecated (you should also be disabling support for TLS 1.0, too). Now let’s break down what each one of those individual algorithms does.

SSL Cipher Algorithm #1: Key Exchange

For all intents and purposes, there are two predominant methods for exchanging session keys with TLS 1.2. The public/private key pair is only used during the handshake with SSL/TLS; the actual communication is encrypted using symmetric session keys that are generated during the handshake. The two methods for key exchange are:

• RSA — The public key encrypts a pre-master secret and sends it to the server, which decrypts it with the private key and uses it for key generation
• Diffie-Hellman — This isn’t actually encryption; it’s a method for two parties communicating on an insecure network to mutually arrive at the same value (the session key)

Diffie-Hellman is a bit more versatile, as it can be performed using an elliptic curve cryptography (ECC)-based approach (lighter and faster, more secure) as well as an ephemeral component (perfect forward secrecy). It’s advised over RSA.

SSL Cipher Algorithms: Digital Signature

Digital signatures play a major role in PKI, so the signature scheme is of vital importance. There are two different methods that are frequently used for digital signatures in TLS 1.2.

• RSA – The certificate’s public key, named after its creators (Rivest, Shamir, and Adleman) can be used to verify the digital signature left by the private key
• DSA – Digital Signing Algorithm, this is method is a bit more complicated but also more versatile.

You can perform DSA using an elliptic curve approach. It’s typically paired with a Diffie-Hellman key exchange, where a key exchange can’t be used to prove ownership of the key pair. Rather, the server uses its private key to encrypt and sign the inputs that are used for key generation and the public key verifies the signature.

SSL Cipher Algorithm #3: Bulk Encryption

Replace “bulk” with “symmetric” and this one makes a lot more sense. This refers to the cryptosystem that is used for the actual communication that takes place once the connection begins. The key size is included in the cipher, as well as what mode the cipher will be encrypting in: block or stream. In TLS 1.2, there’s a bit more freedom in terms of what bulk ciphers and modes can be used. This flexibility has led to some problems, which have been addressed in TLS 1.3. But we’ll get to that in just a moment.

SSL Cipher Algorithm #4: Hashing

Traditionally, this is where you see SHA1 and SHA2. SHA2 is now the standard for SSL/TLS after SHA1 was found to be vulnerable to collision attacks a few years ago. The hashing algorithm serves a couple of important functions. The first, as the name implies, is hashing. Hashing is typically used as a checksum, but there are additional use cases in other contexts. The lesser-known function is as a pseudorandom number generator. This is necessary for key generation in both RSA and Diffie-Hellman schemes.

What do SSL/TLS ciphers actually look like, though? We’ve put together an SSL cipher list:

List of Approved TLS 1.2 Ciphers

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

TLS 1.3: SSL Cipher Suites

TLS 1.3 was designed with an eye toward performance and security (obviously). Historically, the point where SSL/TLS has added the most latency was during the handshake. There are a few reasons for this — one of which was the number of negotiations that had to take place. The other was RSA, which uses massive keys that require lots of CPU resources to encrypt and decrypt data.

The Internet Engineering Task Force (IETF) was able to address this problem by removing RSA. That effectively lops off the first half of the SSL cipher suite. TLS 1.3 cipher suites look like this:

TLS_AES_256_GCM_SHA384

That’s literally just a bulk cipher and a hashing algorithm. The type of certificate (this is a reference to the digital signature scheme) and the key exchange method are no longer included. That’s because RSA is no longer part of things. Key exchange is always going to be a Diffie-Hellman scheme, typically undergirded with ECC. Also, perfect forward secrecy is now compulsory in TLS 1.3, so these schemes are all ephemeral.

And given that Diffie-Hellman needs to be paired with a DSA scheme (read: ECDSA), that portion can also be omitted. In fact, by omitting those portions, the client can essentially lead with the two randoms it will contribute to key generation, which cuts an entire roundtrip out of the handshake.

TLS 1.3 Bulk Ciphers

TLS 1.3 bulk ciphers need to be AEAD (authenticated encryption with associated data), which is an authentication method that hashes a message authentication code (MAC) alongside the encryption process (MAC-and-Encrypt). This reduces burdens for both the server and the client by making it easier to disregard non-authenticated communication. The AEAD requirement also had the benefit of whittling down the number of algorithms that could be supported.

Additionally, TLS 1.3 banned block ciphers. That doesn’t mean block ciphers can’t be used; it just means they can’t be run as block ciphers and need to be run in stream mode.

Hashing Algorithm

In the example above, you see SHA384. That’s a part of the SHA2 family, 384 refers to the length of the digest that’s produced when something is hashed. SHA2 is still the standard, though it’s now suggested you use a 384- or even a 512-bit output.

TLS 1.3: Supported SSL Ciphers

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256