Understanding TLS 1.2 and 1.3 Ciphersuites

This blog post will go over how to better understand a TLS ciphersuite.  It will also cover what is changing for ciphersuites between TLS 1.2 and 1.3.  This is a more technical blog post, but I have found that if you understand TLS more in detail, you can work more effectively with it for your day to day usage of TLS as a programmer, administrator, etc.

TLS Concepts

Before we go over some examples of TLS 1.2 and 1.3 ciphersuites, it will be helpful to first go over some TLS concepts.

TLS (Transport Layer Security) - A cryptographic protocol which enables two parties (the TLS client and TLS server) to identify and authenticate each other and communicate with confidentiality and data integrity. 

Asymmetric encryption (e.g. RSA, elliptic curve) - A form of encryption where both a private and public key are used to encrypt/decrypt data.  For example, you can encrypt data with the private key using RSA and then decrypt the data with the public key using RSA.  Also, you can also encrypt data with the public key using RSA and then decrypt the data with the private key using RSA.

Symmetric encryption (e.g. AES_256_CBC) - A form of encryption where the same key is used for both encryption and decryption of data.

MAC - Message Authentication Code use to authenticate a TLS data record.

TLS is broken into two protocols, the handshake and record protocol.  The handshake protocol is done first, and then the record protocol follows.

TLS handshake protocol - Protocol where the TLS client and server agree on a ciphersuite, authenticate each other (through certificates and cryptographic information), and share secret information to build  symmetric encryption and MAC (Message Authentication Code) keys that will be used to protect TLS records between the TLS client and server.

TLS record protocol - Protocol where the TLS client and server use the negotiated keys to communicate data records to each other with confidentiality (symmetric encryption) and data integrity (MAC).

Cipherspec (e.g. AES_256_CBC_SHA256) - The part of a ciphersuite that tells how the TLS client and server will communicate with confidentiality (symmetric encryption) and data integrity (MAC).

Ciphersuite (e.g. TLS_RSA_WITH_AES_256_CBC_SHA256) - Identifies the cipherspec, and usually also identifies what asymmetric encryption will be used for negotiating the symmetric encryption/MAC keys (at least at TLS 1.2).

Now let’s look at some examples of two TLS 1.2 ciphersuites.

TLS 1.2 Ciphersuite - TLS_RSA_WITH_AES_256_CBC_SHA256

For this example, we will look at the TLS 1.2 ciphersuite TLS_RSA_WITH_AES_256_CBC_SHA256.  This ciphersuite is telling us the following:

RSA - RSA will be used by the TLS client and server to share the pre-master secret to build the symmetric encryption and MAC keys for sending secure records to each other.

AES-256-CBC - AES (Advanced Encryption Standard) with a 256 bit key and CBC (Cipher Block Chaining) will be used to do the symmetric encryption of the data records.

SHA256 - SHA256 will be the hash function to help build the MAC which is used for authenticating the data records.

In this ciphersuite, the TLS server sends its RSA public key (via its certificate) to the TLS client.  The TLS client uses the server’s RSA public key to encrypt a per-master secret and sends this back to the TLS server.  The TLS server then decrypts the pre-master secret with its RSA private key. 

For this ciphersuite, the TLS server’s RSA private/public key is always used to protect the sharing of the pre-master secret.  This is called static RSA, because the same key is being used over and over again to protect the pre-master secret share for the TLS sessions.  If an unwanted party was able to record the TLS session data between the client and server for days, months, even years, and then at a later point in time recover the TLS server’s private key, this unwanted party could go back and decrypt all of this collected TLS session data.  We will look at how this security concern is addressed when we cover forward secrecy later in this post.

This ciphersuite also requires the TLS implementor (e.g. gskit) to handle creating the MAC and encrypt the TLS record with their own functionality.  This is done with a MAC-then-encrypt approach.  There have been security vulnerabilities that have arisen in the past with TLS implementors not properly implementing this MAC-then-encrypt approach.  We will also look at how this security concern of a TLS implementor incorrectly implementing security requirements is better addressed with an API approach called AEAD (Authenticated Encryption with Associated Data).

TLS 1.2 Ciphersuite - TLS_ECDHE_RSA_AES_256_GCM_SHA384

For this example, we will look at the TLS 1.2 ciphersuite TLS_ECDHE_RSA_AES_256_GCM_SHA384.  This ciphersuite is telling us the following:

ECDHE - Elliptic Curve Diffie-Hellman Ephemeral will be used by the TLS client and server to share the pre-master secret to build the symmetric encryption and MAC keys for sending secure records to each other.  Ephemeral means that temporary private/public elliptic curve keys will be built at run time for both the TLS client and server end.

RSA - The TLS server and client (client is optional) will authenticate each other with RSA public key certificates.

AES-256-GCM – An AEAD algorithm is being used to provide TLS record confidentiality (with AES-CTR and a 256 bit key) and authentication (with GHASH).  The GCM stands for Galois-Counter Mode.  The Counter is found in the symmetric encryption AES-CTR, and the Galois is found in the GHASH (Galois HASH).

SHA384 – SHA384 is used for pseudo random functions which I believe are used for building the cipherspec keys (and not to build a MAC for TLS record level authentication).

In this ciphersuite, the pre-master secret is shared between the TLS client and server using ephemeral elliptic curve keys and the Diffie-Hellman algorithm.  If someone was to later steal the TLS server’s private RSA key, they would not be able to decrypt any of the previous TLS session data since it was the ephemeral elliptic curve keys that were protecting the sharing of the pre-master secret.  This is called forward secrecy.

This ciphersuite also uses an AEAD cipherspec.  AEAD is an API approach where the TLS implementor can invoke an API call to pass in plaintext and other input and get back as output the data encrypted and with an authentication tag.  The TLS implementor can also make an API call to pass in the encrypted data/authentication tag and get back output of the data as plaintext.  This API approach helps remove the complexity that was placed on the TLS implementor with the MAC-then-encrypt approach of a ciphersuite like TLS_RSA_WITH_AES_256_CBC_SHA256 and is subsequently considered a more secure way of protecting the TLS record.

Now let’s look at what is changing for TLS 1.3 ciphersuites.

TLS 1.3 Ciphersuites

At TLS 1.3, static RSA is being removed from the handshake and forward secrecy is a requirement for sharing the pre-master secret between the TLS client and server.  As a note, you can still use RSA public key certificates at TLS 1.3 for authenticating a TLS client or server, but the pre-master secret share between the TLS client and server cannot be done with static RSA.  Instead, this pre-master secret share must be done at TLS 1.3 with some form of DHE.  An AEAD algorithm is also required for a TLS 1.3 ciphersuite in order to secure the TLS records.

With the TLS 1.3 requirement that some form of DHE is used to share the pre-master secret between the TLS client and server, the asymmetric encryption portion (e.g. RSA) that we saw in TLS 1.2 ciphersuites has been removed from the TLS 1.3 ciphersuite format, and the TLS 1.3 ciphersuite now has the following format:

TLS_AEAD_HASH

In this new TLS 1.3 ciphersuite format AEAD is the Authenticated Encryption with Associated Data algorithm that will secure the TLS records and HASH is the hash algorithm to be used for HKDF (e.g. used for building the cipherspec keys).

There are now only five ciphersuites at TLS 1.3:

TLS_AES_128_GCM_SHA256

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_CCM_SHA256

TLS_AES_128_CCM_8_SHA256

Let’s now look at a couple of examples of TLS 1.3 ciphersuites.

TLS 1.3 Ciphersuite - TLS_AES_256_GCM_SHA384

This TLS 1.3 example TLS_AES_256_GCM_SHA384 is similar to the TLS 1.2 TLS_ECDHE_RSA_AES_256_GCM_SHA384 ciphersuite that we looked at earlier.  This ciphersuite is telling us the following:

AES_256_GCM - AEAD algorithm to be used for data confidentiality and authentication of the TLS records.  AES-CTR with a 256-bit key will provide confidentiality of the data records, and GHASH will authenticate the data records.

SHA384 - Hash for HKDF (which I believe is used for building the cipherspec keys for this specific ciphersuite).

TLS 1.3 Ciphersuite - TLS_CHACHA20_POLY1305_SHA256

For this example, we will look at the TLS 1.3 ciphersuite TLS_CHACHA20_POLY1305_SHA256.  This ciphersuite is telling us the following:

CHACHA20_POLY1305 - AEAD algorithm for data confidentiality and authentication of the TLS record.  CHACHA20 with a 256-bit key will provide confidentiality of the data records, and POLY1305 will authenticate the data records. 

SHA256 - Hash for HKDF (which I believe is used to build the cipherspec keys for this specific ciphersuite).

TLS Authentication

Although this blog post is primarily about TLS ciphersuites, I thought it would be helpful to briefly talk about TLS authentication to complete our definition for TLS.  Remember in the TLS Concepts section of this post, TLS was defined as the following:

A cryptographic protocol which enables two parties (the TLS client and TLS server) to identify and authenticate each other and communicate with confidentiality and data integrity. 

In this post so far was have seen how the cipherspec portion of the ciphersuite handles the “communicate with confidentiality and data integrity” part of the TLS definition.  For the “identify and authenticate each other“ portion of the TLS definition, this is accomplished through things like certificates and digital signatures.

In general, the TLS client and server identify themselves through the TLS handshake protocol with an x.509 certificate.  This certificate will normally include a subject that has a distinguished name.  This name could be something like “CN=QM1,OU=IBM.MQ.TEST”, if this is a certificate for a queue manager named QM1.  This is how a TLS client or server can be identified. 

For authentication, the remote end that receives the certificate will check if it can trust the certificate by validating the certificate against its trust chain.  Also, the certificate sending end must also prove that it has the private key for the sent public key certificate.  Please note that certificates are public key certificates and they contain a public key (and not a private key).  This private key proof can be done with the certificate sending end creating a digital signature with its private key and sending it to the remote end.  The private key proof can also be done implicitly if the sending end is the TLS server performing an RSA handshake (since the TLS server proves it has the private key by deciphering the pre-master secret in RSA).  To summarize, the trust chain validation of a certificate and proof of possessing the private key completes the authentication requirement for TLS.

Conclusion

This blog post went into some of the technical details of what makes up a TLS ciphersuite.  It also covered some of the ciphersuite changes between TLS 1.2 and 1.3.  At TLS 1.3, forward secrecy and AEAD are now requirements for ciphersuites.  We also looked at how certificates, digital signatures, and ciphersuites help satisfy the definition of TLS. 

If you want to understand TLS ciphersuites more in detail, I have found the best resource to use is the IETF RFC specifications (e.g. RFC 8446 for TLS 1.3).  Hopefully, this deeper look into TLS ciphersuites will help you work more effectively with TLS and IBM MQ.