How TLS Protects Your Web Activity

Image source: https://securedcommunications.com/download--secured-communications.html

In our many articles about how the internet works, we left out an important detail. Many common internet-facing applications secure data before it’s sent out into the world. But how? With an ingenious protocol known as TLS.

What is TLS?

In the olden days of the internet, communication was completely unencrypted. This meant that eavesdroppers could potentially see all of the data sent over the internet. People had to be very careful when sending sensitive information.

This problem was recognized as early as 1994, so the SSL (Secure Socket Layer) protocol was developed. SSL encrypts data at one endpoint and decrypts it at the other, such that data passed between computers was completely unintelligible. Keep in mind that this protocol does not protect data sitting on your computer (“at rest”); it only protects data in transit when two computers connect to each other.

TLS (Transport Layer Security) is a similar protocol to SSL and shares the same purpose. The first version was developed in 1999 and based on SSL 3.0. When SSL 3.0 was found to be insecure, it was completely replaced by TLS. TLS is used for web browsing, but can be used for a variety of services. Today, TLS 1.3 is the latest version of TLS and earlier versions should be avoided.

You may have noticed when browsing the web that some URLs start with “http” and others with “https.” HTTP stands for Hypertext Transfer Protocol, and it is the protocol that retrieves HTML and other media to be displayed by your web browser. HTTPS is a version of HTTP with integrated TLS/SSL. In other words, accessing an “https” website means that your communications with the server are encrypted. It’s recommended that every website switch to HTTPS by purchasing an SSL certificate.

How Does TLS Work

The first question one might ask about encrypted communication is “how do both parties know how to decrypt the messages? Surely they can’t just send the key over the web!” In fact, they can, and we will explain how step by step.

Suppose you are a web browser and you want to connect to a website’s host. The browser will conduct a conversation with the server to establish a secure channel. This conversation is called the TLS handshake.

Step 1: The client will send a “hello” message to the server, containing the TLS/SSL versions it is using, a list of supported cipher suites, and string of random bytes (called the client random).

What is meant by “cipher suite?” We’ll get to that. First of all, a cipher is simply an algorithm to encrypt a message. For example, replacing each letter in a message with a number is a type of cipher. But the ones used by TLS are far more complicated and impossible to break by humans or computers alike.

A cipher can be symmetric or asymmetric. A symmetric cipher is one in which a single key is used to encrypt and decrypt the message. They are most useful when only you want to see the contents of the message, since sharing the key is a security risk. The most common symmetric cipher used by TLS is AES (Advanced Encryption Standard).

Asymmetric ciphers require separate keys to encrypt and decrypt the message, and they are the most important component when establishing a secure session. What makes these algorithms work is that an attacker cannot decipher the message with the encryption key; he must have the decryption key. Therefore, the encryption key, also called the Public Key, can be freely traded between parties without posing a security risk, as long as the decryption key (a.k.a. the Private Key) is not revealed. The principle asymmetric ciphers employed by TLS are RSA (Rivest–Shamir–Adleman) and DHE (Diffie–Hellman).

Now we can define “cipher suite.” A cipher suite contains:

1. A symmetric encryption algorithm (such as AES)
2. An asymmetric encryption algorithm (such as RSA)
3. A Message Authentication Code (MAC), used to authenticate messages

Step 2: The server generates a public/private key pair and responds to the client with: the cipher suite it wants to use, the TLS version it wants to use, a digital certificate, the public key, and another string of random bytes (called the server random).

The digital certificate is supplied by the server’s domain name provider. The client will check with them and ensure that the server is the actual owner of the domain.

After this message is sent, the client and server will use the highest TLS version and the most secure cipher suite available to both.

Step 3: The client generates another string of random bytes (called the pre-master secret), encrypts it with the server’s public key, and sends the result to the server.

Step 4: The server decrypts the message sent by the client with its private key. Now both the server and the client have the unencrypted pre-master secret.

Step 5: The server and the client use the pre-master secret, the client random and the server random to generate another key, called the session key. They should both generate the same key.

Keep in mind that the session key is different than the server’s public/private keys. The former is a key for a symmetric algorithm such as AES, whereas the public/private keys were either RSA or DHE.

Step 6: The server and client will exchanged messages encrypted with the session key to ensure that the handshake worked.

Step 7: If the handshake was successful, the client and server will use the session key for the remainder of session. The MAC is used in conjunction with the session key to authenticate messages.

Once a secure connection is established, there is no need to keep the private key, public key, or pre-master secret.

And that’s it! Except for one small detail: this is how TLS works with RSA. With DHE, there are a couple changes:

1. Along with the public key, the server sends a message encrypted with the private key to prove that the two keys are indeed pairs. The message contains a string known as the DH parameter.
2. Instead of the client generating the pre-master secret randomly, both the server and client use the DH parameter to generate it.

Summary

This was a lot to take in. If there’s anything you derive from the preceding information it’s this:

We use an asymmetric encryption algorithm to exchange information that generates a symmetric encryption key.

The real genius lies in how the encryption algorithms work, so if you’re a sucker for math we highly recommend you checking them out. We will probably explain how they work in future articles.

SafeHouse

SafeHouse will use the techniques shown in this article for its own software. If you found what you read informative, consider checking us out at https://safehouse.dev/.