What happens when you search for a kitten (on the Internet). Part 3: TLS or how to protect your secrets

This is the third part of the series where we talk about what happens when you use your browser to open a URL.

You might also want to check Part1: DNS or where to find the server and Part2: TCP or how not to lose the data on the road.

Now that we established a reliable connection with the server, it is time for us to talk about privacy and security of the data we are about to exchange. We don’t want anyone on the Internet to eavesdrop on our private data, regardless if it is the latest pictures of our pet Dexter or our banking details. Especially, if it is our banking details.

We’ve briefly talked above about the importance of using HTTPS to establish a secure connection. Let’s continue this topic and understand how we protect our data from malicious interventions.

When we use HTTPS, the data that is exchanged between the server and the client is encrypted. Meaning that an onlooker, who managed to intercept the information, won’t be able to understand it, unless they have a key to decrypt data.

When you use HTTPS the data send over the internet is encrypted

In order to exchange the data our browser and the web application will need to have keys to decrypt the messages they receive from each other.

However, how will they exchange the keys in the first place? The communication can be easily intercepted and we cannot simply send the keys, even in a separate package.

This is where Transport Layer Security (TLS) comes into the game. It defines the rules which ensure privacy between our browser and the web application.

Before diving into TLS, let’s talk about encryption types and how they work (in simple terms). There are two types of encryption we’ll use later — symmetric and asymmetric.

Symmetric encryption is fast and efficient for large amounts of data. The same key is used for both encryption and decryption. Therefore, the name is symmetric.

In symmetric encryption we use the same key to encrypt and decrypt data

Asymmetric encryption is a bit more interesting. With it you can encrypt data with a key A, but, unlike the symmetric type, the data cannot be decrypted with the same key and you’ll need another key B for decryption. Likewise, you can encrypt raw data with key B, but you’ll need key A for decryption.

In asymmetric encryption we need separate keys to encrypt and decrypt data

We often call one of these keys public and another private. Public key is shared with others, while the private one is kept as a secret.

When you think of it, there are two consequences, which will be important for us later:

1. If you can decrypt data with key B, it must have been encrypted with key A.
2. Data encrypted with key A can only be decrypted by those who have key B.

Asymmetric encryption is perfect for exchanging information that must only be possible to be decrypted by one party. However, this type of encryption has a disadvantage — it is slow. That’s why we want to use symmetric encryption for bigger bulks of data which will be exchanged between the server and the client. But we’ll use an asymmetric encryption to make exchange of a symmetric key possible!

Now let’s get back to TLS. To establish a secure connection using TLS the browser and the server will need to do another handshake. During this handshake they will not only agree on how to encrypt data, but also create a symmetric encryption key, which will be used to encrypt and decrypt page data at a later stage. The TLS handshake is one of the most critical moments and the security of the handshake will define the overall security of the later data exchange.

We’ll need a couple of important ingredients for this handshake to happen. The client and the server will need to agree on the following:

1. Which TLS protocol to use? For example, TLS 1.3, TLS 1.2, TLS 1.1.
2. Which key exchange algorithm to use? Here are some of the options: RSA, DH, ECDH, DHE, ECDHE, PSK.
3. Which authentication algorithm to use to ensure that we talk to the correct server and not to a malicious impersonator? For example RSA, ECDSA, DSA
4. Which encryption cipher to use? This will be the algorithm for encrypting the actual data sent between the server and client. We can use, for example, AES, CHACHA20, Camellia or ARIA
5. Which hash/MAC function to use? We can choose SHA-256 or POLY1305

For each of these questions we have several available options. A combination of the answers, containing a list of algorithms and protocols, is called a cipher suite.

For example, here is a cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Some cipher suites are stronger than others. Some are so weak, they will give you almost no protection.

The server will be the one who will make a decision which cipher suite to use. You can use ssllabs.com to see which cipher suites are supported by a server. For example, let’s check what ciphers www.petfinder.com uses:

https://www.ssllabs.com/ssltest/analyze.html?d=www.petfinder.com&s=54.174.7.59

Now let’s look at the handshake step by step. We’ll look into the most widely used TLS specification 1.2. The following steps will depend on the encryption algorithms and protocols defined in the cipher suites. That’s why some details are generalised and simplified.

Step 1. Hello

TLS connection is initiated by the client. It sends the server hello message to the server. This message will contain

Client:

• Maximum TLS version supported by the client
• Some random number
• List of supported cipher suites (or protocols and algorithms which the client can work with)

Now, the ball is on the server’s side. Based on what the client can do, the server will choose what techniques will be used for encryption.

Remember keys for asymmetric encryption? Our server has his own pair.

Additionally, it will prepare necessary parameters for the server key exchanged, needed by the key exchange algorithm to create an asymmetric key. With this the server will reply to the client with the hello message followed by additional details.

Server:

• Chosen TLS version and cipher suite
• Random number
• Server’s certificate, which contains its public key
• Server key exchange message including a digital signature which is signed with the server’s private key. This will be used as proof that the message is indeed from the server we intended to talk to.
• Hello done message

Step 2 Authenticating and partial creation of a symmetric key

Upon receiving messages from the server, our browser will make sure that we are talking to the real server, and not to someone who pretends to be it.For this our browser will check server’s certificate for validity and that is matched with the provided digital signature.

Remember, if data can be decrypted with key B, it must have been encrypted with key A. Here, the browser will decrypt data with the public key of the server, if this is successful, we can be satisfied that the server was the one who encrypted the data in the first place. Thus, we’re not talking to an impostor.

With the received details our browser can generate a so-called pre-master key and encrypt it with the public key provided by the server. Therefore this pre-master key can now be decrypted only by the server, so we can safely send it via the Internet.

Client:

• Change cipher spec, indicating that it started using cipher suite according to server instructions
• Client key exchange, containing encrypted pre-master key
• List of all messages exchanged before. This will be used to make sure that no one has intercepted and modified communication between the client and the server.

Step 3. Creating an asymmetric encryption key

Once the server receives information from the client, it uses its private key to decrypt the pre-master key. Now both client and server have this data they can use it to generated the symmetric encryption key.

Server:

• Inform about changing cipher spec, to indicate that from now on the symmetric encryption key will be used.
• Encrypted finish message containing the whole conversation between the client and the server to ensure that there was no data manipulations during data transmission.

Now that both the client and the server have symmetric key, they can start exchanging the data.

Hurrah! Finally, our browser can ask the server for a page we’re interested in, both TCP and TLS will be used during data transportation and our browser will receive the packets, combine them together, render the page and present it to a user.

Summary

It was a long journey, we’ve started with a string of text indicating name of the website. Step by step we’ve done the following:

• decided if HTTP or HTTPs should be used
• found the ip address of the remote server, where web application is located
• established TCP connection
• established TLS connection
• requested and received data packets
• rendered the page and presented it to a happy user

Thank you for reading this far!