In today’s digital world, securing communication over the internet is more important than ever. SSL/TLS (Secure Sockets Layer/Transport Layer Security) is a cryptographic protocol designed to ensure secure communication between clients and servers.
TLS is the successor or we can even say a newer upgraded version to SSL, with TLS 1.2 and TLS 1.3 being the most widely used versions today.
SSL, or Secure Sockets Layer, was the original security protocol developed for HTTP. SSL is now replaced by TLS, or Transport Layer Security, some time ago and is used interchangeably now.
SSL handshakes are now called TLS handshakes, although the “SSL” name is still in wide use.
In this blog, we will explore how SSL/TLS works in detail and how does whole communication becomes secure.
SSL/TLS Flow
Step 1: Client Hello
- The client (such as a web browser) sends the server a “Client Hello” message to start the conversation. This message includes:
- This message includes:
- Supported TLS versions (e.g., TLS 1.2, TLS 1.3)
- Supported cipher suites (encryption algorithms)
- A randomly generated number (Client Random)
Step 2: Server Hello
- The server responds with a “Server Hello” message.
- This message includes:
- The SSL/TLS version selected by the server.
- The cipher suite selected by the server.
- A randomly generated number (random server data).
Step 3: Server Authentication and Certificate Validation
Here the client verifies the details shared by the server alonwith the certificate with its chain and the CN Name. This certificate includes the server’s public key and is signed by a trusted Certificate Authority (CA).
- The client verifies the server’s certificate to ensure:
- It is issued by a trusted CA
- It is valid (not expired or revoked)
- It belongs to the correct domain
- If the certificate is valid, the handshake continues. If not, the connection is terminated.
Step 4: Server Hello Done:
The server indicates that it has finished its initial negotiation steps.
Now both the client and server has the Certificate, the server has the Private Key and the Client has the Public Key shared by the server.
Step 5: Key Exchange (Session Key Generation)
Now, the client generates a "pre-master secret" , encrypts it with the server’s public key (from the server certificate), and sends it to the server.
The pre-master secret and the session keys are related but distinct in the SSL/TLS handshake process. Here’s how they work and how they are used:
Pre-Master Secret
- Generation: The pre-master secret is a random value generated by the client during the SSL/TLS handshake.
- Encryption: The client encrypts the pre-master secret using the server’s public key (found in the server’s certificate) and sends it to the server.
- Decryption: The server decrypts the pre-master secret using its private key.
Pre-Master Secret = Random Value + Certificate Public Key shared aboveBoth client and server use this pre-master secret, along with Client Random and Server Random, to generate the session key.
Step 6: Generate Master Secret
Now, both the Client and the Server have the PMS Key [ Pre-Master Secret], they will now generate a Common Master Secret.
Derived from the pre-master secret and the random values from the client and server. It serves as the basis for generating session keys.
Master Secret
- Creation: Both the client and server use the pre-master secret, along with the random values exchanged in the “Client Hello” and “Server Hello” messages, to generate the master secret.
- Derivation: The master secret is derived using a specific pseudo-random function (PRF) defined by the SSL/TLS protocol, which combines the pre-master secret and the two random values.
Now the question arises how is the master secret calculated on both the client and server end can be the same?
The master secret is calculated using a process defined by the SSL/TLS protocol, ensuring that both the client and the server independently derive the same value. This process involves combining the pre-master secret with random values exchanged during the handshake.
Here’s how the master secret is calculated and why it is the same on both sides:
Key Materials Used in the Calculation:
- Pre-Master Secret: A random value generated by the client.
- Client Random: A random value sent by the client in the
"Client Hello"message. - Server Random: A random value sent by the server in the
"Server Hello"message.
Master Secret = Pre-Master Secret + Client Random + Server RandomStep 7: Session Key Encryption
The master secret is used to generate the session keys. These keys are used for symmetric encryption and MAC (Message Authentication Code) during the secure session.
Yes, the session keys are also the same on both the client and server sides. They are derived from the master secret using a process that ensures both parties generate identical keys. Here’s a detailed explanation of how the session keys are generated:
Key Materials Used in the Calculation
- Master Secret: Generated during the SSL/TLS handshake process.
- Client Random: A random value sent by the client in the “Client Hello” message.
- Server Random: A random value sent by the server in the “Server Hello” message.
Session Key = Master Secret + Client Random + Server RandomThe session keys are derived from the master secret using a pseudo-random function (PRF) defined by the SSL/TLS protocol. The process combines the master secret with the client random and server random values.
Ensuring Both Sides Have the Same Session Keys
Same PRF Process: Both the client and server use the same PRF process defined by the SSL/TLS protocol to combine these values into the key block.
Master Secret: Both the client and server independently generate the same master secret during the handshake.
Client Random and Server Random: Both the client and server have the same client random and server random values from the handshake messages.
Step 8: Session Key Encryption
The client sends a “Finished” message, encrypted with the session key, indicating that the client side of the handshake is complete.
The server also sends a message indicating that it will start using the session keys for encrypting the rest of the communication.
The server sends a message, encrypted with the session key, indicating that the server side of the handshake is complete.
Once the session key is generated, both parties switch to symmetric encryption (e.g., AES, ChaCha20) for faster and more secure communication.
Till now in the above process, asymmetric encryption was being used.
From this point, the client and server use the session keys to encrypt and decrypt the data they exchange.
Step 9: Secure Data Transmission
- All subsequent communication is encrypted using the session key.
- This ensures that data remains confidential and cannot be intercepted by attackers.
Use of Symmetric and Asymmetric Encryption in SSL/TLS
SSL/TLS uses both symmetric and asymmetric encryption to ensure secure communication:
Session Keys: Session keys derived from the master secret are used for encrypting and decrypting data during the session, ensuring data confidentiality and integrity.
Asymmetric Encryption:
Initial Key Exchange: During the SSL/TLS handshake, asymmetric encryption is used to securely exchange the pre-master secret.
Server Authentication: The server’s public key (contained in the server’s digital certificate) is used by the client to encrypt the pre-master secret. Only the server, with its private key, can decrypt this pre-master secret.
Symmetric Encryption:
Session Encryption: After the pre-master secret is exchanged and the master secret is derived, symmetric encryption is used to encrypt the actual data exchanged between the client and the server.
Session Keys: Session keys derived from the master secret are used for encrypting and decrypting data during the session, ensuring data confidentiality and integrity.
Conclusion:
- Asymmetric Encryption: Used for secure key exchange and server authentication during the SSL/TLS handshake.
- Symmetric Encryption: Used for encrypting the actual data exchanged during the session, ensuring efficient and fast communication.
By combining both types of encryption, SSL/TLS provides a secure, efficient, and authenticated communication channel over the Internet.
I’m a DevOps Engineer with 3 years of experience, passionate about building scalable and automated infrastructure. I write about Kubernetes, cloud automation, cost optimization, and DevOps tooling, aiming to simplify complex concepts with real-world insights. Outside of work, I enjoy exploring new DevOps tools, reading tech blogs, and play badminton.
