May 24, 2022 0

What Is an SSL/TLS Cipher Suite?

in Web Security

(10 votes, average: 5.00 out of 5)

Loading...

Online security is only as strong as the cipher suites it relies on. With this in mind, let’s examine what an SSL/TLS cipher suite is and how it contributes to cyber security

These days, it’s crucial to use encryption for secure online communications. Without strong encryption, your communications are visible to anyone who wishes to look. They’re vulnerable to man-in-the-middle attacks, which means your data can be intercepted, stolen, and used for malicious purposes. Transport layer security (TLS) certificates promise security, but according to digital transformation firm NTT, insufficient TLS is one of the top five vulnerabilities that increases the risk of your organization’s data becoming exposed.

Cybersecurity experts apply complex mathematical algorithms to encrypt the message to prevent data theft during transmission via the internet. So, before the two parties begin to exchange messages, they first need to communicate which algorithms they both support (i.e., this is the cipher suite) and agree upon which ones to use. This is done by exchanging a series of messages as part of what’s known as a “TLS handshake.” Ultimately, it’s the server that makes the final cipher selections.

So, let’s explore what is a cipher suite is and how it works in helping to establish secure, encrypted communications over the internet.

What Is a Cipher Suite?

The encryption strength of an SSL/TLS secure connection depends on the cipher suite it uses. You might well ask, what is a cipher suite? Put simply, a cipher suite is a collection of different algorithms, protocols, and all the other good stuff that encrypts and decrypts data between two communicating parties (the client browser and the website server) while keeping it secure from outsiders.

A cipher suite is generally displayed as a long string of seemingly random information — but each segment of that string contains essential information. Generally, this data string is made up of several key components:

• Protocol (i.e., TLS 1.2 or TLS 1.3)
• Key exchange or agreement algorithm
• Digital signature (authentication) algorithm
• Bulk encryption algorithm
• Message authentication code algorithm (MAC)

In the field of cryptography, a cipher is a program that is used to encrypt and decrypt data. All these algorithms support multiple ciphers. The cipher defines the detailed steps to be taken for encryption and decryption processes.

What a Cipher Suite Looks Like in TLS 1.2 & TLS 1.3

Okay, so now that we know what a cipher is, it’s time to see what it looks like with two quick examples. Cipher suites vary depending on the protocol in use. A TLS 1.0 protocol has a different handshake than other versions of the TLS protocol (i.e., TLS 1.2 or TLS 1.3).

A cipher suite might look like this:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Or, it could look like this:

TLS_AES_256_GCM_SHA384

The first is an example of a TLS 1.2 cipher suite, which includes key exchange and signature algorithms (more on that in a minute). The second is an example of a TLS 1.3 cipher suite.

If this looks like a whole bunch of gibberish, no worries — we’ll break down the components of a cipher suite for you a little later in the article.

Different Versions of SSL/TLS Support Different Cipher Suites

As we touched on earlier, cipher suites are exchanged during a process known as the TLS handshake (formerly known as an SSL handshake). In a TLS handshake, the client will send a ClientHello message along with all the algorithms it supports. The server will return the ServerHello and the algorithms it supports from the client algorithm list.

The algorithms selected by the server from the client list are finalized as the cipher suite before the two parties move to create a secure connection. If the two parties don’t share any common cipher suites, the server will abort the connection immediately. It’s also important to note that TLS 1.2 cipher suites can’t be negotiated with TLS 1.3 connections and vice versa.

We have been talking about TLS 1.2 and TLS 1.3 in our article. Let’s explore both versions of the handshake more in depth and which cipher suites the two versions of the TLS protocol support.

TLS Handshake

TLS 1.2, the predecessor to 1.3, takes two round trips from both the client and the server to complete the initial handshake. The following figures show TLS 1.2 and TLS 1.3 handshakes. As opposed to TLS 1.2, TLS 1.3 makes one less round trip during the handshake saving hundreds of milliseconds. Furthermore, if a server and client have connected previously, TLS 1.3 permits zero roundtrips (0-RTT) handshakes to make the connection even faster. Basically, the fewer roundtrips required, the faster it will be.

The following figures represent the trips made by the client and the server during TLS 1.2 and TLS 1.3 versions of the handshake:

Perfect Forward Secrecy

Perfect forward secrecy is a term used to describe a cryptographic method that creates unique keys for every communication session. As such, perfect forward secrecy protects a client’s past sessions even if a server’s keys are stolen or otherwise compromised in the future. It’s facilitated through the use of the ephemeral Diffie-Hellman (aka Diffie-Hellman ephemeral, or DHE) key agreement digital signature algorithm.

While TLS 1.2 doesn’t require perfect forward secrecy, TLS 1.3 sure does! The Internet Engineering Task Force (IETF) made perfect forward secrecy a requirement for version 1.3 by removing all static RSA and Diffie-Hellman cipher suites.

Ciphers Supported by TLS 1.2 And TLS 1.3

TLS 1.3 offers better security and a faster handshake than its predecessor TLS 1.2 (and its pre-predecessor TLS 1.0). The major difference between these two versions of the TLS protocol lies in the following:

• TLS 1.2 is the most commonly used TLS protocol. Its cipher suites include algorithms with cryptographic vulnerabilities. There are a total of 37 TLS 1.2 cipher suites, which contains four main cipher components (we’ll show an illustration later that helps explain this a little later).
• TLS 1.3 is the newer and improved version of TLS 1.2. It’s less commonly used than TLS 1.2 and supports only five or so cipher suites. These suites contain only two cipher components. (Again, we’ll address this more a little later in an illustration shortly.)  

The following table shows us the supported algorithms for each function in TLS 1.2:

Key Exchange or Agreement Algorithms	Digital Signature Algorithms (Authentication)	Bulk Encryption Algorithms	Hashed Message Authentication Code (HMAC) Algorithms
Diffie-Hellman	Digital signature algorithm (DSA)	Advanced encryption standard (AES), either GCM or CBC modes	POLY1305
Diffie-Hellman Ephemeral	Elliptic-Curve digital signature algorithm (ECDSA)	ARIA	SHA-256
Elliptic-Curve Diffie-Hellman (ECDH)	Rivest-Shamir-Adleman (RSA)	Camellia
Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE)		ChaCha20
Pre-shared key (PSK)
Rivest-Shamir-Adleman (RSA)

TLS 1.3 eliminated support of several insecure algorithms, most notably RSA. The National Institute of Standards and Technology (NIST) lists the following cipher suites as supported by TLS 1.3:

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

The Internet Engineering Task Force (IETF) also says that TLS_CHACHA20_POLY1305_SHA256 is another cipher suite that should be supported in TLS 1.3.

How Do Client and Server Agree Upon a Cipher Suite? 

The choice of cipher suite is agreed upon in the initial SSL handshake between client and server (but it’s ultimately the server that decides which one gets used). When the client sends a hello message at the beginning of the conversation, it also sends a list of the ciphers that it is compatible with. When the server receives the message, it chooses the set of algorithms from the list that it is compatible with. The communication is then carried out using the algorithms that both parties agree to.

To understand the SSL handshake, imagine going to a country where you don’t know the language. You might feel lost without the ability to speak to other people. Now imagine going shopping in a local market where you’re visiting. The first thing you’d do is to find out if the salesperson speaks a language you know. In the same way, the client browser will ask the website server it’s connecting to whether it uses a particular cipher suite.

When traveling, you and the salesperson might agree to use a common language you both speak to discuss the products in the store. In the SSL handshake, the client and the server agree to use a particular cipher suite that is compatible with both parties to ensure secure communication between them.

Let’s understand all four sets of algorithms and discuss their roles in the encryption process.

Breaking Down the Cipher Suite’s Algorithms

As mentioned above, there are four kinds of algorithms in the cipher suite. Each fulfills a different role in establishing a secure, encrypted connection. A client and a server can support different cipher suites based on the SSL/TLS version they use. Many companies also have specific policies about the minimum strength of encryption that is required to communicate. So, based on all these factors, the client and the server agree on a particular cipher suite to use.

Key Exchange or Agreement Algorithm

There are two types of encryption algorithms at the most basic level — symmetric and asymmetric. In symmetric encryption, the same key is used to encrypt and decrypt data. With asymmetric encryption, different keys are used to encrypt (public key) and decrypt (private key) the data. SSL/TLS certificates use asymmetric encryption, with separate keys for encryption and decryption, to establish a secure channel for data exchange. After that, they switch to a symmetric connection.

To establish the secure channel, information that both parties can use to generate session keys must be exchanged securely. A so-called “key exchange algorithm” takes care of this during the handshake process.

The client hello is the first step of the SSL handshake. The client hello includes the following:

• Session ID — the key for encrypting the session is attached in the client hello.
• Client cipher suite list —a list of cipher algorithms supported by the client browser that it sends to the server. The server chooses the ciphers that the two parties should use throughout the rest of the session.
• Random data —random data is added to the client hello to make the session key unidentifiable to cybercriminals.
• Compression algorithm — an algorithm used to compress data is also a part of client hello to speed up the encryption process. This is a topic for another day, though.

The key exchange algorithm protects the session ID, or encryption key, from prying eyes. This makes it an indispensable part of the cipher suite. Some of the most popular key exchange and agreement algorithms include

• Rivest-Shamir-Adleman (RSA) — deprecated in TLS 1.3
• Diffie-Hellman (DH) and Diffie-Hellman Ephemeral (DHE) — only ephemeral DH key agreement is allowed in TLS 1.3 (DH was deprecated)
• Elliptic-curve Diffie-Hellman (ECDH)

The following figure shows how the static (non-ephemeral) Diffie-Hellman key agreement (i.e., key generation process) works just to provide some basic understanding. Note: The key in a Diffie-Hellman key generation process is static (long term); this differs from an ephemeral (temporary) key that you’ll find in the Diffie-Hellman ephemeral key generation process.

In order to preserve the secrecy of these keys, DHE keys are generated randomly at the beginning of every communication session. But since they’re short-term “secrets,” they’re less likely to be stolen.

Digital Signature Algorithm

The signature algorithm, also called the authentication algorithm, authenticates the identity of the sender of the message to the receiver. It is crucial for secure communication as it ensures that communication is happening with a legitimate server. (In other words, a bad guy isn’t impersonating the certificate owner and communicating in their stead.)

In TLS 1.3, recommended digital signature algorithms include RSA (PKCS#1 variants) and ECDSA. DSA signatures were deprecated in the move from TLS 1.2 to TLS 1.3.

The client and the server exchange ephemeral (temporary) public keys to calculate the same symmetric key for encrypting the messages. These public keys are not the same as the host certificate public keys. They are randomly generated at the beginning of each connection.

The server creates a hash of the ephemeral public key using its private key to prove to the client that the ephemeral key has come from a legitimate source. Once a secure channel is established, the temporary key is dropped. The client can verify the identity of the sender by comparing the hashes of the data and the signature.

The following figure shows how the signature algorithm comes into play in TLS encryption:

Bulk Encryption Algorithms

Once the client and website server are on the same page after the key exchange or generation, it’s time to move on to the main communication. Enter the bulk encryption algorithms. A symmetric bulk encryption algorithm encrypts the plaintext input into a fixed length ciphertext output using a single key. So, regardless of the length of the plaintext, the length of the ciphertext will be the same.

There are two types of bulk ciphers in use today:

• Stream cipher —A stream cipher encrypts the data one byte at a time. A keystream is used for encryption and decryption purposes. Some well-known stream ciphers include ChaCha, RC4, and Chameleon.
• Block cipher —A block cipher enciphers the data after diving it into blocks of specific lengths and running each block through rounds of cryptographic processes. Data encryption standard (DES) and triple data encryption standard (3DES) uses 8-byte (64-bit) blocks. The advanced encryption standard (AES), which is the go-to industry standard algorithm that replaced the others, has a block size of 16 bytes, or what amounts to 128 bits.

TLS 1.2 and TLS 1.3 use AES as their bulk encryption standard, which has different available key sizes — 128 bits, 192 bits, or 256 bits. The bigger the key, the better the security.

Hash-Based Message Authentication Code (HMAC) Function

The HMAC protects the integrity and authenticity of the handshake communication. This helps to prevent bad guys from intercepting or modifying data in transit as the handshake is occurring. It does this by using a cryptographic hash function alongside a secret key to verify that data hasn’t been altered in some way.

But don’t worry, we won’t get too technical on all of that here as it’ll take us down another rabbit hole. Check out this great video by Computerphile to understand what HMAC is and more about how it works:

Final Thoughts on SSL Cipher Suites & Their Uses in Secure Online Communications

A cipher suite is a collection of algorithms that allows a client and a server to communicate securely. Remember the foreign language analogy from earlier? Despite having fewer algorithms included in each cipher suite, TLS 1.3 is more secure and faster than its predecessor due to its decreased handshake round trips. The client and the server mutually agree which algorithm cipher suite they both support.

In the long run, TLS 1.2 will be completely replaced by TLS 1.3 — but until then, both the protocols are in use.

• #Cipher Suite
• #SSL Cipher Suite
• #TLS 1.2 cipher suite
• #TLS 1.3 cipher suite