Ever wondered what really happens when you browse to a site with 'https' and a padlock 🔒🔒 in your browser?

Most people think it means some sort of security.
But very few know why it matters, or how it works.

But, it is crucial for developers to understand ‘https‘ or ‘Transport Layer Security‘(TLS). Because, it is what will protect APIs, databases or any web services- through encrypted communication.
Knowing how TLS works- can help you debug issues, optimize performance of secure applications, and protect user data.


And today, I’m going to show you exactly how it works—step by step.

But Why is TLS Necessary?

So, let me first provide the context as to why TLS (Transport Layer Security) is necessary at all? And what purpose does it serve?

A server and a client browser want to communicate securely. But the medium over which they have to communicate is fundamentally insecure . And they haven’t communicated before.

It’s like two lovers trying to exchange romantic letters. But their letters can be read by anybody …

The main purpose of TLS (transport layer security) is to provide a way, for a server and a client browser to communicate securely , even over a very insecure medium.
It does so by facilitating a safe exchange of a session key.
And all future communication is encrypted with this session key

The TLS Handshake: A Quick Overview

Here is a quick overview of TLS 1.3 handshake:

Client Hello: Your browser says, “Hey Server. Let’s talk securely—here’s what I can do.”
Server Hello: The server replies, “Cool, here’s my plan and proof of who I am.”
Verification & Key Creation: Both sides verify trust and generate a session key.
Done: They start chatting securely with encrypted data.

Now, let’s dig into each step.

1. Client Hello

• First, your browser knocks on the website’s door and says:

  “Hey, I want to talk securely. “

• “Here is a list of cipher suites (encryption options), a random number, and my key share.”

1.1 So, what is a cipher suite?

A recipe for secure communication—specific algorithms for authentication, key exchange, encryption, and hashing.

The client and server need to agree on one.

1.2 And, why the random number ?

2 reasons:

• It stops hackers from replaying old conversations.

• It helps generate a secret session key that is very difficult to guess.

1.3 What is client’s key share

The client is sharing it’s half of the Diffie-Hellman Key Exchange .

But, what is a Diffie-Hellman ?

Diffie-Hellman is a way for two people to create a secret key even if someone is eavesdropping. They each start with a public number and mix it with their own secret number to create a shared secret. Even though an outsider sees the public numbers, they can’t easily figure out the final shared secret.

In this case, the shared secret will be used to create session keys

Wikipedia has a great picture to illustrate the concept of Diffie-Hellman with paints:

2. Server Hello

The server gets the message and fires back with a “ServerHello” message.

It says: “Got it! Here’s how I want to encrypt things” (selects a cipher suite)

“Here is a random number & my key share”

“And one more thing . Here is my digital certificate along with proof that I actually own the private key.”

2.1 So what happens when a cipher suite is selected?

Remember, that the client sent it’s list of supported encryption options.

And now the server is selecting and finalizing the protocols of it’s choice among those options.

2.2 But, why is this random number needed?

Told you before.

For preventing replay Attacks & contributing to the randomness of Session Key.

2.3 What is Server’s key share

The Server is sharing their half of the Diffie-Hellman Key Exchange .

After exchanging key shares and random numbers, both parties can perform a Diffie-Hellman calculation to generate a shared secret .

2.4 What is a digital certificate for the server?

The digital certificate acts as the Identity of the Server. It is kind of like a passport, but for digital realm.

Specifically, it associates the server’s asymmetric key pair (Public & Private Key) with a specific identity (i.e., the website you are visiting)

A server has to prove it’s identity to a trusted certificate authority to get such digital certificate.

2.5 How does the server prove that it own’s it’s private key

It does so by providing a digital signature.

With a digital signature, only the person who has the private key can sign the data.

But, anyone who has the relevant public key/ digital certificate- can verify the validity and authenticity of the signature.

3. Verification and Session key Creation

Now, before the client trusts the server, it does some detective work

• The client first checks the server’s digital certificate.

• Then the client verifies server’s digital signature ,a fancy way of proving, “Yeah, the server actually own this private key.”

• Then, both client and server use their key shares to generate a shared secret (encryption key), using Diffie-Hellman algorithm.

Both parties then derive session keys and exchange 'Finished' messages.

3.1 How the client verifies the server’s certificate?

It checks if that certificate was issued by a trusted certificate authority and checks the certificate’s status online.

3.2 Why the client verifies server’s digital signature?

By, verifying the digital signature the client can be 100% sure that the server is who it is claiming to be.

Client can be sure about the, the server’s ownership of it’s private key

3.3 How Session Keys are Created?

Both Client & Server have completed the Diffie-Hellman Key Exchange and calculated a shared Secret.

That shared secret is combined with the client random and server random- to create session keys.

4. Done

At this point, the Client and Server have verified the Server’s Identity and Established mutual Session Keys – which means the TLS Handshake is finally complete! 🔒 ✅

Now they can start sending Application Data, protected by the session keys derived from the TLS Handshake.

Congratulations, you now understand TLS handshake

In summary, TLS uses asymmetric cryptography and key change protocols like Diffie-Hellman for securely generating and exchanging a session key. The session key is then used for encrypting the data transmitted by one party, and for decrypting the data received at the other end.