An In-Depth Look at TLS

The ‘S’ in HTTPS, the lock icon in the top left of your browser, the lack of a suspicious “this site is insecure” warning – most everyone who uses the internet is familiar with these, yet fewer know what exactly they mean, and even fewer still understand how it works behind the scenes.

Transport Layer Security, or TLS, is a cryptographic protocol, commonly used on top of insecure HTTP, providing internet users with encryption of communication, authentication of the parties involved, and integrity of the data being transmitted. TLS was designed as a replacement of SSL, an earlier protocol. Fundamentally, it is what enables secure browsing on the modern web, and almost all sites today have some form of HTTPS (HTTP over TLS) enabled. It is also used to secure email, file transfers, instant messaging, and many other application-layer protocols.

TLS accomplishes encryption via the use of asymmetric cryptography to exchange a shared secret key, which is then used for symmetric encryption for the remainder of the communication. Authentication is accomplished via a digital certificate provided by the server (and optionally the client) that is signed by a trusted 3rd-party Certificate Authority, guaranteeing that the server is who it claims to be. Lastly, once a secure channel of communication is established, message integrity is ensured via the use of either Message Authentication Codes or digital signatures.

The exact cryptographic algorithms used can vary, and the sets that are supported are known as cipher suites. A cipher suite consists of:

• Asymmetric key exchange algorithm (e.g. RSA, Diffie-Hellman)
• Authentication algorithm (e.g. RSA, Digital Signature Algorithm)
• Symmetric bulk encryption algorithm (e.g. AES), strength (e.g. 128-bit, 256-bit), and mode (e.g. GCM, CBC)
• Hashing algorithm (e.g. SHA256) used for MACs, digital signatures, etc.

Once a TCP connection has been established, a TLS connection is initiated with the TLS handshake. The exact details can vary depending on the version of TLS and the cipher suite chosen.

An older, widely used option, now considered insecure, would be TLS 1.2 with RSA key exchange. This handshake would go something like this:

1. ClientHello: The client initiates the handshake, sending the supported TLS versions and cipher suites to the server. It also includes the Client Random, a string of random bytes.
2. ServerHello: The server responds with its TLS certificate (a.k.a. SSL certificate), the TLS version and cipher suite selected from the ClientHello, and the Server Random.
3. Authentication: The client validates the server’s certificate with the issuing certificate authority. The certificate, signed by the authority, contains the server’s public key. This serves as proof that they public/private key pair is owned by the server.
4. ClientKeyExchange: The client generates a Premaster Secret, and encrypts it with the public key from the server’s certificate. This encrypted secret is sent to the server.
5. Generate Session Key: Both client and server generate a shared secret session key from the Client Random, Server Random, and Premaster Secret.
6. Client ChangeCipherSpec: The client sends this message to tell the server that it is ready to switch to encrypted communication. It follows it with a “Finished” message, containing a hash of the handshake messages up to this point and encrypted with the session key.
7. Server ChangeCipherSpec: The server does the same, encrypting the hash with the session key. Now, both client and server have verified that they have a shared symmetric session key, and encrypted communication can begin.

From TLS 1.3 onward, RSA key exchange is no longer supported, due to its lack of perfect forward secrecy (meaning exchanges that are secure today could be compromised in the future in the event of private keys getting leaked). The TLS 1.3 handshake is a bit shorter, and looks like this:

1. ClientHello: The client initiates the handshake, sending the supported TLS versions, cipher suites, and proactively generated parameters (e.g. Diffie-Hellman) to be used for generating the shared secret.
2. Server Generates Session Key: The server generates the session key from the Client/Server Randoms and the parameters from the client.
3. ServerHello and Finished: The server responds with its TLS certificate, a digital signature (to prove ownership of the private key corresponding to the certificate), the chosen version and cipher suite, the Server Random, and the cryptographic parameters. It already has the secret, so it sends Finished, too.
4. Client Generates Session Key: The client generates the session key from the Randoms and the parameters from the server. It verifies the certificate and signature, and sends Finished, encrypted with the shared secret session key. Encrypted communication is established.

Notably, the handshake is much more concise in TLS 1.3, due to the pre-computed cryptographic parameters generated in steps 1 & 2, made possible by the reduced list of supported cipher suites. No longer does a cipher suite have to be mutually agreed on before the cryptographic ingredients can begin getting generated.

The use of ephemeral keys instead of static key pairs for generating the shared secret provides Perfect Forward Secrecy, meaning that even in the future event of a private key getting compromised, the messages will remain secure, as the key can’t be used to retroactively decrypt captured traffic.

Additionally, due to the lack of using the static RSA key pairs to exchange a secret (which is no longer considered secure), the server must prove ownership of the public key in the certificate by providing a digital signature that can be verified with the public key.

Now that a secure communication channel is established, the integrity of the encrypted data being transmitted can be ensured via a HMAC (Hash-based Message Authentication Code). The message and shared secret are concatenated together and then hashed, and this hash value (the MAC) is sent with the message. The recipient can independently verify the integrity of the message by calculating its own hash and ensuring it matches the MAC. Alternatively, digital signatures can be used, wherein the sender encrypts the message hash with its private key (signs it), and the recipient decrypts this signature with the corresponding public key and ensures it matches its independently generated message hash.

Long story short, there are a wide variety of cryptographic techniques that go into enabling TLS, ranging from decades-old asymmetric and symmetric encryption, public key infrastructure and digital certificates, one-way hash functions, and more. As the complex security landscape continues to evolve, it is imperative to stay up to date on which of these cryptographic algorithms are still considered secure, and to consistently evaluate whether the cipher suite being used meets the necessary security requirements for each situation.