Rate this article: (14 votes, average: 3.50)
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).
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 cipher suites contain four individual ciphers that all work together during the handshake. A TLS/SSL cipher suite looks like this:
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.
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:
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.
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.
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.
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.
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:
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:
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 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.
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.
You can save significant money by buying your EV SSL certificate direct instead of through your web hosting company. We sell PositiveSSL certificates for as little as $72.18/year.Compare SSL Certificates