How HTTPS Works — TLS Encryption Explained

When you open a website over HTTPS, everything sent between your browser and the server is encrypted. Nobody in between — your ISP, your router, a Wi-Fi hotspot — can read the content. Here's exactly how that works.

The Problem: Encrypting Data in Transit

Encryption needs a key. The simplest approach is a symmetric key — both sides use the same key to encrypt and decrypt. It's fast and works well for large data.

The catch: both sides need to have that key first. If you simply send the key over the wire, anyone intercepting the connection gets the key too, and from that point can decrypt everything. This is a man-in-the-middle (MITM) attack.

Two Types of Encryption Algorithms

Since the public key is openly shared, anyone can encrypt data using it — and only the private key holder can decrypt it. So someone can send you data securely by encrypting it with your public key, and nobody else can decrypt those bytes — not even someone who intercepts them — except you with your private key.

The downside is that asymmetric algorithms are computationally expensive. Using RSA for every byte of a large file transfer would be impractical. So TLS uses a hybrid approach — asymmetric only for the initial handshake, then symmetric for all actual data.

The TLS Handshake (simplified)

This is the negotiation that happens before any application data flows.

1. Client Hello

• The client (browser) sends a random plaintext string to the server to initiate the connection.

2. Server Public key sending

• The server responds with the server's public key.

3. Client Generates & Sends Symmetric Key

The client:

1. Generates a symmetric key
2. Encrypts it using the server's public key from the certificate
3. Sends the encrypted key along with a ChangeCipherSpec message — signalling it will now switch to symmetric encryption

Only the server's private key can decrypt this. Even if someone intercepts this packet, they cannot read the symmetric key inside.

4. Server Decrypts and Acknowledges

The server uses its private key to decrypt the payload and extract the symmetric key. Now both sides hold the same key.

The server sends its own ChangeCipherSpec acknowledgement.

5. Encrypted Data Transfer

From here, all communication uses the symmetric key (e.g. AES). The slow asymmetric work is done — the rest of the connection is fast.

Why Your Router Cannot Read HTTPS

TLS is end-to-end encrypted between the client and the server. The symmetric key never appears in plaintext on the network — it was exchanged inside an asymmetric-encrypted envelope.

Your mobile hotspot, your home router, your ISP — they all see the IP packets flowing through them. They can see that you connected to a particular server (the IP address is visible), and they can see the encrypted bytes you sent and received — but those bytes are ciphertext, meaningless without the symmetric key, which only your device and the target server hold.

Summary

1. Asymmetric (RSA): used once, during the handshake, to securely deliver the symmetric key
2. Symmetric (AES): used for all actual data, fast and efficient
3. The result: an encrypted tunnel where only the two endpoints can read the contents — even the infrastructure routing the traffic cannot

What Was Simplified — For the Curious

The explanation above intentionally left out some details to keep things approachable for beginners. Here's what's actually happening under the hood:

1. Multiple TLS versions and cipher suites: TLS has gone through several versions — TLS 1.0, 1.1, 1.2, and the current standard TLS 1.3. Each version defines which encryption algorithms are allowed. The specific algorithm used isn't always RSA for key exchange or AES for data — each version supports a menu of options. The combination of key-exchange algorithm + encryption algorithm + hashing algorithm is called a cipher suite (e.g. TLS_AES_128_GCM_SHA256).
2. Client Hello carries more than a random string: In step 1, the client doesn't just send a random string — it also sends the list of TLS versions it supports and the list of cipher suites it supports, so both sides can agree on what to use.
3. Server selects from the client's list: When the server responds in step 2, it picks one TLS version and one cipher suite from what the client offered. All subsequent steps follow the rules of that chosen combination.
4. The server sends a certificate, not a raw public key: The server doesn't hand over a bare public key. It sends a certificate — a document that contains the public key along with the server's domain name, validity dates, and a digital signature from a Certificate Authority (CA) like DigiCert or Let's Encrypt. The CA's signature is what allows your browser to trust the key actually belongs to the server you intended to connect to and not an impersonator. The server's certificate is also accompanied by a certificate chain — intermediate certificates linking back to a root CA that your browser already trusts.
5. TLS 1.3 changed key exchange significantly: In TLS 1.2, RSA was commonly used for key exchange as described above. TLS 1.3 removed RSA key exchange entirely in favour of Ephemeral Diffie-Hellman (ECDHE).