9. TLS

In this lesson we will understand how TLS actually works. We will uncover stuff step by step.

We assume that you have studied our previous two lessons. The one on Diffie Hellman key exchange and the one on RSA public key algorithm.

The final attack that we are going to defend!

In the previous lesson, we saw how RSA digital signature helped us defend against the Man in the Middle attack during Diffie Hellman key exchange process.

To recap quickly: Bug signed his message with his private key and distributed his public key to everybody. When Ant received Bug's message, he verified the signature with Bug's public key. If the verification passed then it meant that the message was not altered during transmission and the message is from Bug only.

There's a possibility of an attack here. And its going to be the last attack. After this Ant and Bug will talk securely forever.

Let us take a situation where the attacker would have intercepted Bug's public key and replaced Bug's public key with his own public key (that is, the attacker's public key) and then sent it to Ant.

Illustration of -- Bug's public key intercepted and replaced by Man in the Middle's public key! — Bug's public key intercepted and replaced by Man in the Middle's public key!

Ant would have thought that its Bug's public key because there's no verification step here to make sure that Ant has received the public key from Bug. This missing step is really dangerous, let us see how.

All messages that Bug would sent to Ant will get intercepted by the attacker. The attacker will modify the message, and sign the message with his own private key.

Now the interesting part -- when Ant will verify the signature, the verification will pass because Ant is verifying the signature with attacker's public key not with Bug's public key.

When the verification passes, Ant thinks that the message is truely from Bug. But that ain't the case. The attacker is modifying and re-signing the messages with his own private key. Since, Ant has attacker's public key the signature verification is getting passed.

This is again the Man in the Middle attack! The attacker that is our man in the middle of the conversation is able to modify the messages without Ant or Bug realising it.

How can Ant trust the public key that he has received? How he can make sure that the public key is actually from Bug and not from someone acting on Bug's behalf?

The missing step is: Chain of Trust

During Diffie Hellman key exchange, we know that, Bug signed his message with his private key and sends his public key to Ant.

To understand this part, let us assume that Ant is the client (the browser). And Bug is our server. Bug is the server of news.ycombinator.com (Hacker news).

Our browser has received public key from the hacker news server. Now the problem is, how can the browser trust this public key?

How can the browser make sure that this public key actually belongs to the hacker news server and not to someone in the middle...?

This problem is solved with the help of two entities called as -- Intermediate Certificate Authority (Intermediate CA) and Root Certificate Authority (Root CA).

The umbrella term for these two entities is simply -- Certificate Authority. Imagine it like, Certificate Authority is the company and it has two employees under this company named as Intermediate CA and Root CA. The company has to manage and take care of these two employees.

As we will move forward, it all will make sense intuitively. I hope :)

The task of the Intermediate CA is to verify that the one who is claiming to be the owner of news.ycombinator.com has control over the server of news.ycombinator.com.

Once this verification is completed, the Intermediate CA signs with its private key the Public Key Certificate of the server. It's also called as TLS certificate.

This public key certificate as the name suggests has the public key of the server.

Intermediate CA has its own public key certificate which contains the public key of the Intermediate CA.

Now, when our browser requests the public key from the server. The server sends two things -- the server's public key certificate and Intermediate CA's public key certificate.

Hacker news certificate's chain of trust. — Hacker news -- chain of trust.

When the browser receives the server's public key certificate and Intermedia CA's public key certificate, the browser looks at the server's certificate, and sees that the server's certificate is signed by the Intermediate CA.

If you look at the image above, you will see that, the hacker news server certificate is signed by (or issued by) the Intermediate CA (Let's Encrypt E5). The Intermediate CA's public key certificate is signed by the Root CA.

The browser traverses this path: server certificate to intermediate CA certificate to root CA certificate.

Every browser has a pre-populated list of Root CA's public keys that it can trust. The browser developers populate this list. And keep this list updated. For example, here's the Chrome root store.

This pre-populated list of Root CAs public keys in the browser is called as root store.

The browser looks at the Root CA's public key certificate, extracts the Root CA's public key from it and then it searches in its root store.

The browser proceeds to the next step, only if the Root CA is at the end of the chain and is found in the root store.

Once the browser has verified the Root CA. The browser takes the Root CA's public key from its certificate and verifies the Intermediate CA's public key certificate signature. Then it takes the Intermediate CA's public key and verifies the server public key certificate signature.

Once the signature verification steps passes then it means that the server's public key certificate is valid. And the public key contained in the server certificate belongs only to the hacker news server.

Btw, why was it so important to verify the Root CA...?

See, the attacker can modify the server certificate and the intermediate CA certificate as they are sent over the network. But the Root CA certificate is in-built into the browser. So there's no way for an attacker to touch the Root CAs certificates.

So, once we verify the Root CA, any modifications to the intermediate CA certificate and server certificate will be caught during signature verification.

Hence, the most important thing in the chain is to -- have a trusted Root CA at the end of the chain.

So our takeaway with all of this is -- with the help of chain of trust, the browser verifies that the public key indeed belongs to the server only not to anybody else!

One last thing: we developers don't have to deal with any of this. This all happens automatically in the TLS handshake process. A developer just needs to install a TLS public key certificate in its server with help of a CA, for example, by using Let's Encrypt CA.

Finale -- The TLS Handshake 🤝

Finally, Ant and Bug will be able to talk securely. They will have an encrypted communication without any worries. Because we have arrived at the pinnacle of secure communication -- Transport Layer Security (TLS).

TLS handshake is the process that makes the client and server exchange the secret key with help of Diffie Hellman key exchange. See the aim here is to understand the handshake process intuitively.

Illustration of simple TLS handshake. — TLS handshake for intuitive understanding.

We will learn what happens at each step and you will see that everything that we have studied so far -- symmetric encryption, cryptographic hashing, RSA asymmetric cryptography, digital signatures, Diffie Hellman key exchange. All this will come together to make TLS happen!

The TLS handshake starts with the client saying "Hello" to the server.

The server on receiving the "Hello" selects a base, modulus and private number. Then it calculates the public number for Diffie Hellman key exchange.

The public number is signed with the server's private key and then its sent along with the server certificate and Intermediate CA's certificate.

The client verifies the certificate using Chain of Trust.

The RSA signature of the server's Diffie Hellman public number is verified.

The client uses its private number and the server's public number to arrive at the shared secret key 🔑.

Then client sends its Diffie Hellman public number with a HMAC of all the previous messages and a "Finished" string.

The HMAC (Hash Based Message Authentication Code) takes in two inputs. Both are required. The first input is the Diffie Hellman secret key that the client calculated and the second input is all the message history between the client and server so far. The HMAC produces a hash value by combining those two inputs.

This stops the attacker from modifying this message. Because if the attacker changes the message, the HMAC verification will fail on the server end. And also the attacker cannot generate a new HMAC because it doesn't have access to the client's Diffie Hellman secret key (a required input of the HMAC function)!

The server calculates the shared secret key 🔑 using the client's Diffie Hellman public number that it just received.

Then the server verifies the client message's HMAC. It verifies it by hashing all the previous messages along with the Diffie Hellman secret key that the server just calculated.

This verification proves that the secret key that server has calculated is the same as the client's one.

Server sends a "Finished" message to the client along with the HMAC of all the previous messages just like the client did.

The client verifies the HMAC that it received from the server by hashing its own message history along with the Diffie Hellman secret key that the client has. This proves that the server and client both have the same message history. This proves that the attacker has not modified anything in between.

Now, the client and the server are ready with their shared secret key 🔑!

All future messages will now be encrypted using a symmetric encryption algorithm that the client and server support. The shared secret key will be used as the encryption key.

Since, only the client and the server have the shared secret key, their communication is securely encrypted!

We are finally being able to talk securely. Now, let the client and server enjoy the talking. Let us move on ;)

TLS or SSL ... ?

google.stanford.edu in netscape navigator 4 — Google on Netscape Navigator 4. Emulator: https://oldweb.today.

Before TLS came around, Netscape developed Secure Sockets Layer (SSL) around 1995 to have encrypted communication between a client and a server. It was inspired from Secure Network Programming (SNP) which was led by Simon S. Lam in 1993.

SSL 1.0 and SSL 2.0 had many security flaws. Then SSL 3.0 stayed for some time. Finally, TLS 1.0 came around with improved security in 1999. But with time, some possible attacks made us to shift to TLS 1.1 then TLS 1.2 and the latest TLS 1.3.

Only TLS 1.2 and TLS 1.3 are safe to use today. Rest all are deprecated.

So, today when you hear someone talk about SSL, they are reffering to TLS 1.2 or TLS 1.3 ;)

More than 85% of websites of all the Internet now run on TLS. A big thanks to the Let's Encrypt initiative. They provide free TLS certificates!

HTTPS ... ?

HTTP (HyperText Transfer Protocol) is the request-reponse protocol of the Web. It works in a client-server environment. When you open GitHub.com, your web browser (the client) sends a GET request to GitHub's server. The GitHub server program processes your request and returns a response. The response can be a HTML file, or JSON or any text.

HTTPS (HyperText Transfer Protocol Secure) is the HTTP protocol running with TLS. So when you see HTTPS in the URL, it means that the communication between your browser and the server is encrypted with TLS.

This marks the end of this course. Oh man, it was so much to absorb. First of all, hats off to you for studying all along!

Woody Toy Story GIFfrom Woody GIFs

Thank you so much for taking your valuable time to read these lessons. I hope some day these concepts get put to use by you in some form. ❤️

If these lessons have been helpful to you, consider following me on Twitter. There I will post about my future projects and valuable resources. I will try to be useful always.

Once again, thank you so much! see ya!

Credits

Below are some resources I used to study TLS. I got tremendous value from these resources so it's my responsibility to let my readers know this. You can check them out if you are curious. But you don't necessarily need to, as we have covered the required concepts in this article.