SSL/TLS and HTTPS Encryption

The Spy Analogy

Two spies communicating over a public radio frequency face two problems. First: How do I know this is really you and not an enemy impersonating you? Second: How do we speak so others cannot understand us even if they are listening?

TLS solves both problems for the internet. It is the protocol behind the padlock in your browser, the https:// in every URL, and the security that makes online banking possible. Without it, every password, credit card number, and private message would travel across the internet as readable text.

From SSL to TLS: A Brief History

SSL (Secure Sockets Layer) was created by Netscape in 1995. It enabled early e-commerce but was quickly found to have significant vulnerabilities.

The name "SSL" persists in common usage (people still say "SSL certificate"), but the actual protocol in use today is TLS 1.2 or TLS 1.3.

The TLS Handshake (Simplified)

Before encrypted application data can flow, the client and server must negotiate which cryptographic algorithms to use, exchange keys, and verify each other's identity. This is the TLS handshake.

TLS 1.2 Handshake (Simplified)

1. ClientHello
   → Client sends: TLS version, list of supported cipher suites, random number (ClientRandom)

2. ServerHello + Certificate + ServerHelloDone
   → Server picks cipher suite, sends its digital certificate, sends ServerRandom

3. Client verifies certificate with a Certificate Authority

4. Key Exchange
   → Client generates pre-master secret, encrypts it with server's public key, sends it
   → Both sides derive the session keys from: pre-master secret + ClientRandom + ServerRandom

5. Finished (both sides)
   → Both sides send a "Finished" message encrypted with the new session key
   → Handshake complete; application data flows

TLS 1.3 Handshake (Faster)

TLS 1.3 reduces handshake to 1 round trip (down from 2 in TLS 1.2):

1. ClientHello
   → Client includes: key share (Diffie-Hellman public value), supported cipher suites

2. ServerHello + Certificate + Finished
   → Server responds with its key share, certificate, and is immediately finished

3. Client Finished
   → Client confirms, handshake complete

TLS 1.3 also supports 0-RTT resumption for returning connections — zero additional round trips for repeated connections to the same server.

Certificate Authorities: The Trust Anchors

A certificate proves a server's identity. But who vouches for the certificate itself?

Certificate Authorities (CAs) are trusted third parties — organizations like DigiCert, Let's Encrypt, Sectigo — whose root certificates are pre-installed in your browser and operating system. When a server presents a certificate signed by a trusted CA, your browser accepts it.

The chain of trust:

Root CA (trusted by your OS/browser)
    └── Intermediate CA (signed by root)
            └── Server Certificate (signed by intermediate)

How a certificate is issued:

1. A website owner generates a key pair (public + private)
2. They submit a Certificate Signing Request (CSR) to a CA
3. The CA verifies they control the domain (DNS challenge or file upload)
4. CA signs the certificate with its own private key
5. Browser verifies the signature using the CA's public key (pre-installed)

Let's Encrypt made this process free and automated, enabling HTTPS to become the default for virtually every website.

Symmetric vs Asymmetric Encryption: Why TLS Uses Both

Asymmetric encryption uses a key pair: anything encrypted with the public key can only be decrypted with the private key.

• Advantage: No need to share a secret key in advance
• Disadvantage: Very slow — computationally expensive (RSA, ECDH)

Symmetric encryption uses one shared key for both encryption and decryption.

• Advantage: Very fast (AES-256 operates at near memory-bus speeds)
• Disadvantage: Both parties must have the same key — how do you share it securely over an insecure channel?

TLS solves this by using both:

1. Asymmetric cryptography during the handshake — to securely agree on a shared session key
2. Symmetric cryptography for all application data — fast, efficient encryption once both sides share the key

This is called a hybrid cryptosystem. The expensive asymmetric operation happens once; all subsequent traffic uses the cheap symmetric cipher.

HTTPS: HTTP + TLS

HTTPS is simply HTTP running over a TLS connection. The HTTP protocol itself is unchanged — TLS wraps it in an encrypted, authenticated tunnel.

The padlock in your browser means:

• The connection to the server is encrypted (nobody can read it in transit)
• The certificate was verified by a trusted CA (the server is who it claims to be)

What the padlock does NOT mean:

• The website itself is safe or trustworthy
• The server is not hosting malware
• Your account cannot be hacked through application vulnerabilities

Attackers increasingly use HTTPS on phishing sites. The padlock confirms encryption, not legitimacy.

Attacks TLS 1.3 Prevents

TLS 1.3 also mandates Perfect Forward Secrecy (PFS): session keys are ephemeral (Diffie-Hellman key exchange). Even if a server's private key is stolen in the future, previously recorded sessions cannot be decrypted.

TLS 1.2 vs TLS 1.3 Key Improvements

Key Takeaways

• TLS replaced SSL — all versions prior to TLS 1.2 are deprecated and insecure
• The handshake negotiates keys and verifies identity; TLS 1.3 does this in 1 round trip
• Certificate Authorities form a chain of trust that browsers verify automatically
• TLS uses asymmetric cryptography to exchange keys, then symmetric for fast data encryption
• HTTPS = HTTP + TLS; the padlock means encryption and identity verification, not safety
• TLS 1.3 removes all weak algorithms and mandates Perfect Forward Secrecy