Skip to main content

How Encryption Happens Between Client and Server: A Step-by-Step Guide

In the modern web, securing the communication between a client (like a browser) and a server is crucial. Every time you visit a website with "HTTPS" in the URL, encryption is happening behind the scenes. But how does this encryption process actually work? In this blog, we'll break down the encryption process step by step, focusing on the TLS/SSL handshake, which is the protocol used to establish a secure connection.

We'll also include a flow diagram to make it easier to understand!


What is TLS/SSL?

Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL) are protocols that provide encryption between a client and a server. They ensure that any data transmitted between the two parties remains confidential and cannot be intercepted or tampered with by third parties.

Here’s how the process works:


Step-by-Step: How Encryption Happens Between Client and Server

1. Client Hello

The encryption process begins when the client (typically a web browser) wants to establish a secure connection with the server. The client sends a message called the Client Hello, which includes:

  • Supported encryption algorithms (cipher suites) the client can use.
  • A randomly generated number, called the client random.
  • The version of TLS/SSL the client supports.

This message helps the server understand what kind of encryption the client is capable of.

2. Server Hello

The server responds with the Server Hello, which includes:

  • The encryption algorithm (cipher suite) chosen by the server, from the list the client provided.
  • Another randomly generated number, called the server random.
  • The server’s digital certificate, which contains the server’s public key. This certificate is issued by a trusted Certificate Authority (CA).

At this point, the server is letting the client know how it will encrypt the communication and providing the information needed to start the encryption process.

3. Certificate Validation

The client now performs an important task: it validates the server’s digital certificate. This ensures that the certificate was issued by a trusted Certificate Authority (like Let's Encrypt, Verisign, etc.) and that it hasn’t expired or been tampered with.

If the certificate is valid, the connection continues. If it isn’t (e.g., it's self-signed or expired), the client will typically show a warning or abort the connection.

4. Key Exchange and Pre-Master Secret

Once the client trusts the server’s certificate, it will generate a pre-master secret, which is just a randomly generated value. This value is essential for creating the encryption keys later.

The client encrypts the pre-master secret using the server’s public key (retrieved from the server’s digital certificate) and sends it to the server. This encryption ensures that only the server, with its private key, can decrypt this message.

5. Decryption by Server

The server decrypts the pre-master secret using its private key. Only the server can decrypt this message, ensuring that no third parties can interfere.

6. Generation of Session Keys

Now that both the client and server have the same pre-master secret, they use this value, along with the client random and server random, to generate the session keys.

These session keys are symmetric encryption keys that will be used to encrypt and decrypt all further data transmitted during this session.

  • Symmetric encryption is much faster than the asymmetric encryption used earlier in the process, which is why the two parties switch to using symmetric keys for the bulk of the data transmission.

7. Client Finished

The client sends a message, encrypted with the newly generated session key, indicating that the secure connection is ready to be used.

8. Server Finished

The server responds with a similar message, also encrypted with the session key, confirming that the secure session is established.

9. Secure Communication

At this point, both the client and server use the same session keys to encrypt and decrypt data. The communication is now secure, ensuring that any data transmitted between the client and server remains private and cannot be intercepted or altered.


Flow Diagram: Client-Server Encryption Process

arduino
Client Server | | |----------------Client Hello--------------->| | | |<----------------Server Hello---------------| | (includes server certificate) | | | |---Certificate Validation (Client Side)---->| | | |--------Pre-Master Secret Encrypted-------->| | (using server’s public key) | | | |<------Pre-Master Secret Decryption---------| | (using server’s private key) | | | |---Session Keys Created (Client & Server)-->| | | |---------------Client Finished------------->| | | |<--------------Server Finished--------------| | | |========= Secure, Encrypted Communication ===|

Key Components in the Encryption Process:

  • Public and Private Keys: The server’s public key is used by the client to encrypt the pre-master secret. The server’s private key is used to decrypt it. This ensures secure transmission of the secret value.
  • Symmetric Keys: After the handshake, both the client and server use the same symmetric session keys for faster and more efficient encryption of data.
  • Certificate Authorities (CA): The digital certificate, which contains the server’s public key, is validated by the client against trusted Certificate Authorities. This ensures authenticity.

Why is Encryption Important?

Encryption plays a critical role in ensuring confidentiality, integrity, and authentication during data transmission between a client and a server. It protects sensitive information like passwords, credit card details, and personal data from being intercepted or modified by attackers.

Without encryption, any data sent over the internet would be vulnerable to eavesdropping, tampering, or theft, making it extremely dangerous to use services like online banking, shopping, or even email.


Final Thoughts

The encryption process, while complex behind the scenes, is a fundamental part of securing modern web communication. Understanding how encryption works between a client and server can help you appreciate the effort that goes into protecting your online activities.

Next time you see "HTTPS" in your browser's URL, you'll know that your data is safe, thanks to the TLS/SSL handshake and encryption process happening in the background!

Comments

Popular posts from this blog

Advanced Kafka Resilience: Dead-Letter Queues, Circuit Breakers, and Exactly-Once Delivery

Introduction In distributed systems, failures are inevitable—network partitions, broker crashes, or consumer lag can disrupt data flow. While retries help recover from transient issues, you need stronger guarantees for mission-critical systems. This guide covers three advanced Kafka resilience patterns: Dead-Letter Queues (DLQs) – Handle poison pills and unprocessable messages. Circuit Breakers – Prevent cascading failures when Kafka is unhealthy. Exactly-Once Delivery – Avoid duplicates in financial/transactional systems. Let's dive in! 1. Dead-Letter Queues (DLQs) in Kafka What is a DLQ? A dedicated Kafka topic where "failed" messages are sent after max retries (e.g., malformed payloads, unrecoverable errors). ...

Project Reactor Important Methods Cheat Sheet

🔹 1️⃣ subscribeOn – "Decides WHERE the Pipeline Starts" 📝 Definition: subscribeOn influences the thread where the data source (upstream) (e.g., data generation, API calls) runs . It affects the source and everything downstream (until a publishOn switches it). Flux<Integer> flux = Flux.range(1, 3) .doOnNext(i -> System.out.println("[Generating] " + i + " on " + Thread.currentThread().getName())) .subscribeOn(Schedulers.boundedElastic()) // Change starting thread .map(i -> { System.out.println("[Processing] " + i + " on " + Thread.currentThread().getName()); return i * 10; }); flux.blockLast(); Output: [Generating] 1 on boundedElastic-1 [Processing] 1 on boundedElastic-1 [Generating] 2 on boundedElastic-1 [Processing] 2 on boundedElastic-1 [Generating] 3 on boundedElastic-1 [Processing] 3 on boundedElastic-1 📢 Key Insight: ...

🔄 Kafka Producer Internals: send() Explained with Delivery Semantics and Transactions

Kafka Producer Internal Working Apache Kafka is known for its high-throughput, fault-tolerant message streaming system. At the heart of Kafka's data pipeline is the Producer —responsible for publishing data to Kafka topics. This blog dives deep into the internal workings of the Kafka Producer, especially what happens under the hood when send() is called. We'll also break down different delivery guarantees and transactional semantics with diagrams. 🧠 Table of Contents Kafka Producer Architecture Overview What Happens When send() is Called Delivery Semantics Kafka Transactions & Idempotence Error Handling and Retries Diagram: Kafka Producer Internals Conclusion 🏗️ Kafka Producer Architecture Overview Kafka Producer is composed of the following core components: Serializer : Converts key/value to bytes. Partitioner : Determines which partition a record should go to. Accumulator : Buffers the records in memory be...