SSL/TLS Protocol

When you open a website an notice a padlock next to its address, it's more than a comfort symbol – it's a guarantee that your data is encrypted, authenticated, and protected.

This invisible shield is made possibly by SSL/TLS, the protocol that secure the modern web.

Let's dive deep into how SSL/TLS works, why it's crucial, and what actually happens when you visit a secure website.

Current Flow of HTTP

What Is HTTP?

HTTP (Hyper Text Transfer Protocol) is the foundation of data communication on the web.

It defines how a browser (client) and a web server communicate – sending requests and receiving responses.

Example Flow: HTTP Request-Response

Let's say you visit:

https://example.com

Here's what happens step-by-step:

1 DNS Resolution

• Browser asks DNS: “What is the IP of example.com?”
• DNS replies: “It's 93.194.200.77”

2 TCP Connection

• Browser opens a TCP connection to the server's IP at port 80 (default HTTP port).

3 HTTP Request Sent

Browser sends a plaintext message:

GET /login HTTP/1.1
Host: example.com
User-Agent: Chrome
Cookie: session=123abc

Everything here – including cookies, headers, and possibly passwords in POST data – is sent in plain text.

4 Server Response

Server replies:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 5423

followed by the webpage content (HTML, CSS, JS, etc.)

5 Browser Renders Page

• The connection may stay open (persistent TCP) for more requests.

Problem: It's All Plain Text

HTTP by itself does not encrypt anything.

That means anyone between you and the server (like ISPs, public Wi-Fi routers, or attackers) can:

• Read everything (passwords, cookies, tokens)
• Modify data in transit (inject malware or fake content)
• Impersonate the server (man-in-the-middle attacks)

 So, while HTTP defines how to communicate, it doesn't ensure secure communication.

The 3 Main Security Problems with HTTP

The Need for SSL/TLS

To fix these vulnerabilities, the web needed a security layer – something that could:

1. Encrypt communication
2. Verify identity of servers
3. Prevent tampering

That's where SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) come in.

SSL/TLS doesn't replace HTTP. It just wraps around it to make it secure.

That's why you see:

HTTPS = HTTP + SSL/TLS

What Is Encryption?

Encryption is the process of converting readable data (plaintext) into unreadable data (ciphertext) so that only authorized parties can read it.

When you encrypt something, you lock it using a key – and only someone with the right key can unlock (decrypt) it.

Encryption is the science of making data useless to everyone except the intended recipient.

Simple Analogy

Imagine you write a letter and put it inside a locked box. You send that box to your friend – but only your friend has the key to open it.

Even if someone intercepts the box in transit, they can't read the letter without the key.

That's encryption in a nutshell.

Core Terms

Types of Encryption

There are two main types of encryption based on how keys are used.

1 Symmetric Encryption

• Uses the same key for both encryption and decryption.
• Fast and efficient.
• But the key must be shared securely between sender and receiver.

Example:

Real-world example:

When you use TLS (after handshake) – all actual data is encrypted symmetrically using a session key.

2 Asymmetric Encryption

• Uses two different keys:
  • A public key (shared with everyone)
  • A private key (kept secret)
• When one key encrypts, only the other can decrypt.

Example:

Real-world example:

Used during SSL/TLS handshake to securely exchange the symmetric session key.

What Is SSL/TLS?

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols that ensure secure communication between two systems – typically a browser (client) and a web server.

• SSL was the original version developed by Netscape in the 1990s.
• TLS is its improved, more secure version that replaced SSL (though the term “SSL” is still used informally).

Together, they provide three pillars of security.

What Is the TLS Handshake?

The TLS handshake is the protocol phase where:

• Client and server agree on cryptographic algorithms
• Server proves its identity
• Both derive shared session keys
• Secure communication begins

After the handshake, all traffic is encrypted.

How SSL/TLS Works – The Handshake Process

When you connect to secure website (say https://example.com), your browser and the server perform a process called a TLS Handshake to establish trust and generate encryption keys.

Let's understand this step by step:

Step 1: Client Hello

Your browser sends a Client Hello message to the server, containing:

• The supported TLS version (e.g., TLS 1.2, 1.3)
• A list of cipher suites (encryption algorithms)
• A random number (used later for key generation)

“Hey server, I would like to talk securely. Here's what I can do.”

Step 2: Server Hello

The server responds with:

• Its chosen TLS version and cipher suite
• Its own random number
• Its digital certificate (issued by a trusted Certificate Authority)

The certificate includes:

• The domain name
• The server's public key
• The CA's signature

“Sure! Let's use this encryption method, and here's my identity proof.”

Step 3: Certificate Verification

Your browser now validates the certificate:

• Is it signed by a trusted by a trusted CA?
• Is it valid (not expired or revoked)?
• Does the domain match the certificate?

If everything checks out, the handshake continues.

If not, you see the dreaded:

“Your connection is not provide.”

Step 4: Key Exchange

Now, both the client and the server need to agree on a shared session key for encrypting data.

Two methods are commonly used:

A. RSA Key Exchange (Older TLS versions)

• The browser generates a pre-master secret, encrypts it using the server's public key, and sends it.
• The server decrypts it using its private key.
• Both sides then derive the same session key.

B. Diffie-Hellman (Modern TLS 1.3)

• Both sides exchange ephemeral public keys.
• Using the Diffie-Hellman algorithm, they each compute the same session key, independently.
• The session key is never transmitted – ensuring perfect secrecy.

Step 5: Session Established

Using the exchanged data, both the client and server derive identical session keys.

These keys are symmetric – used for both encryption and decryption – because symmetric encryption is much faster.

From this point, all data is securely encrypted.

Step 6: Encrypted Communication Begins

Now, every request and response (like HTTP GET or POST) is:

• Encrypted using the session key.
• Authenticated to ensure integrity.

The browser shows a padlock symbol – indicating a successful secure connection.

Step 7: Connection Termination

When the session ends:

• The session key is discarded
• A new handshake is required for a new session

TLS 1.2 Handshake (Classic Model)

Step 1 ClientHello

Client sends:

• Supported TLS versions
• Supported cipher suites
• Random values (ClientRandom)
• Supported key exchange methods

Purpose: “Here's what I support”

Step 2: ServerHello

Server responds with:

• Chosen TLS version
• Chosen cipher suite
• Random value (ServerRandom)
• Digital certificate (contains public key)

Purpose: “Here's what we will use.”

Step 3: Certificate Verification

The client:

• Verifies the certificate signature
• Validates domain name
• Checks expiration
• Verifies CA chain

Certificate authorities like:

• Let's Encrypt
• DigiCert

If verification fails -> connection stops

Step 4: Key Exchange

Depends on cipher suite.

Modern method: ECDHE (Ephemeral Diffie-Hellman)

Both sides:

• Generates temporary key pairs
• Exchange public values
• Compute shared secret

Shared secret = Session key material

Important:

The private keys are never transmitted.

Step 5: Finished Messages

Both sides send:

• Encrypted “Finished” message
• Proof they derived the same session key

If successful -> secure channel established.

TLS 1.3 Handshake (Modern Version)

Major improvements:

• Removed weak algorithms
• Enforced forward secrecy
• Faster hanshake (1 round-trip)
• More encrypted handshake data

Step 1: ClientHello

Includes:

• Supported cipher suites
• Key share (ECDHE public value)
• Supported versions

Client immediately sends key exchange data.

Step 2: ServerHello

Server replies with:

• Chosen cipher
• Its key share
• Certificate
• CertificateVerify
• Finished message

From this point, most communication is encrypted.

Role of Digital Certificates and Certificate Authorities (CA) in HTTPS

Digital certificates and Certificate Authorities (CAs) are what make HTTPS trustworthy. They ensure that you are really communicating with the intended website and not an attacker.

Digital Certificate

A digital certificate is an electronic document that proves the identity of a website. Certificates follow the X.509 standard.

What a Certificate Contains

• Domain name (e.g., www.example.com)
• Public key of the website
• Owner / organization details
• Certificate Authority (issuer)
• Validity period
• Digital signature of the CA

Why We Need SSL Certificates

Even with asymmetric encryption, a smart hacker can perform a Proxy Attack. They can intercept the server's public key and replace it with their own public key. The client thinking they are talking to the server, actually sends the secret key to the hacker.

This is where SSL Certificates comes in.

An SSL certificate is a digital “identity card” for a website, issued by a Certificate Authority (CA) like Let's Encrypt.

How the Certificate is Created:

1. The Server sends its Public Key to a CA.
2. The CA verifies the server's identity (domain ownership).
3. The CA creates a certificate containing the server's Public Key and signs it with a Digital Signature.