How TLS works

TLS (Transport Layer Security) is a cryptographic protocol that provides secure communication over a computer network. It is widely used in HTTPS, email, messaging, and other protocols. Here's a detailed breakdown of how TLS works, from the moment a connection is initiated to the end of the secure session.

🔐 Goals of TLS

TLS provides four main properties:

Confidentiality – Data is encrypted to prevent eavesdropping.
Integrity – Ensures data is not modified in transit.
Authentication – Confirms the identity of one or both parties.
Forward Secrecy (optional) – Ensures past sessions remain secure even if long-term keys are compromised.

🧾 TLS in Action: The Handshake

Step 1: Client Hello

The client (e.g., browser) initiates a secure connection by sending a "ClientHello" message that includes:

Supported TLS versions
Supported cipher suites
A random number (used later for key generation)
Extensions, including the server name (SNI)

Step 2: Server Hello

The server responds with:

The chosen TLS version
The selected cipher suite
Its own random number
Its digital certificate (usually X.509, contains public key and identity info)
Optionally, key exchange parameters

The digital certificate is signed by a Certificate Authority (CA) that the client trusts.

Step 3: Authentication and Key Exchange

Now the client must verify the server's identity:

The client checks the certificate’s validity (expiry, domain match, CA signature)
If valid, the client proceeds to key exchange

The exact method depends on the chosen key exchange algorithm:

In RSA-based TLS, the client generates a "pre-master secret", encrypts it with the server's public key (from the certificate), and sends it to the server.
In Diffie-Hellman or ECDHE (modern, preferred), both sides agree on a shared secret using ephemeral keys (provides forward secrecy).

Step 4: Session Key Generation

Both sides now derive the session key from:

The pre-master secret (or Diffie-Hellman result)
The client and server random numbers

This key is used for symmetric encryption, because it’s much faster than public-key cryptography.

Step 5: Finished Messages

Both client and server send a "Finished" message encrypted using the derived session key.
These messages confirm that future communications are encrypted and that the handshake succeeded.

🔒 Secure Data Transfer

Now that both sides share a session key:

All data is encrypted using a symmetric cipher (e.g., AES)
A MAC (Message Authentication Code) or AEAD (Authenticated Encryption with Associated Data) ensures data integrity

📤 Closing the Connection

When either side wants to close:

They send a "close_notify" alert
Both sides discard the session key

🧠 Summary Diagram

Client                         Server
  |----- ClientHello -------->|
  |                           |
  |<------ ServerHello -------|
  |<----- Certificate --------|
  |                           |
  |--- (Key Exchange) ------->|
  |                           |
  |--- Finished (encrypted)-->|
  |<-- Finished (encrypted) --|
  |                           |
  |<==== Secure Data ========>|
  |                           |
  |------ close_notify ------>|

✅ TLS Versions

TLS 1.0 / 1.1: Obsolete, insecure
TLS 1.2: Widely used, secure with modern settings
TLS 1.3: Simplified, faster, more secure (no RSA key exchange, removes obsolete features)

📘 Real World Example (HTTPS)

You type https://example.com
Your browser starts a TLS handshake
Verifies the server’s certificate
Negotiates a secure connection
Then HTTP data is transmitted securely on top of TLS