Lessons (5, study in order)

Lesson 1 - Why HTTP isn't enough and needs a TLS layer

Beginner · about 8 min

Goal: First understand the three problems being solved, rather than memorizing algorithm names right away.

Three troubles with HTTP's plaintext transport

An ordinary HTTP message is plaintext -- any intermediate device on the path (public WiFi, an ISP, any hop) can see, or even alter, your data. Broken down, that's three specific problems:

- Confidentiality -- content can be seen by others (e.g. passwords, chat logs)
- Integrity -- content can be silently altered (e.g. injecting malicious code into a downloaded file)
- Authentication -- you have no idea whether the other side is really the site you think it is (e.g. someone on public WiFi faking a bank's login page)

TLS is exactly what fills in these three gaps for HTTP

HTTPS = HTTP + TLS. TLS sits between HTTP and TCP, and is essentially transparent to the application above (browser/HTTP) -- the application uses it exactly as before, while TLS underneath handles all three: confidentiality (encryption), integrity (tamper protection), and authentication (certificates).

Key takeaways

• HTTP's plaintext transport has three problems: it can be seen, altered, and you don't know who's on the other end
• TLS = filling in confidentiality + integrity + authentication for HTTP
• HTTPS is simply HTTP running on top of TLS

Lesson 2 - How symmetric and asymmetric encryption work together

Beginner · about 10 min

Goal: This is the core of TLS's entire design -- get this lesson clear and every step of the handshake that follows will make sense.

Symmetric encryption: fast, but safely handing over the key is a hard problem

Symmetric encryption (AES, ChaCha20, ...) uses the same key for encryption and decryption, is very fast, and suits encrypting large amounts of data.

The problem: how do you safely tell the other party this key? If you send the key over in cleartext, anyone along the way can intercept it, and the encryption was for nothing.

Asymmetric encryption: solves key exchange, but is slow

Asymmetric encryption (RSA, elliptic curves, ...) has a pair of keys: the public key can be freely handed to anyone, the private key stays with its owner alone. Content encrypted with the public key can only be decrypted with the corresponding private key.

This solves "how to safely exchange a key" -- but asymmetric encryption's computational cost is far higher than symmetric encryption's, so using it to encrypt large amounts of data (e.g. an entire web page) is too expensive.

TLS's answer: combine the two

★ First use asymmetric encryption to negotiate a symmetric key, then switch entirely to symmetric encryption for transferring data.

Asymmetric encryption is only used during the handshake, exchanging just a small amount of information; once the symmetric key is negotiated, all subsequent page content travels over the much faster symmetric encryption. This is the secret to being "both secure and fast."

Key takeaways

• Symmetric encryption is fast, but key exchange is the hard problem
• Asymmetric encryption can safely exchange keys, but is too slow for encrypting large amounts of data
• TLS's approach: negotiate the key asymmetrically, transfer data symmetrically

Lesson 3 - Digital certificates and the CA trust chain

Advanced · about 10 min

Goal: Anyone can hand out a public key -- so why trust that this one really belongs to this site?

A public key alone can't prove "who it belongs to"

If a server sends you its public key directly, how do you know this public key wasn't sent by an impersonating man-in-the-middle? A public key carries no identity information on its own -- anyone can generate their own key pair and claim to be any website.

Digital certificates: signed and vouched for by a third party (a CA)

A digital certificate binds a "domain" to a "public key", and is then signed and vouched for, using its own private key, by a widely-trusted third party (a CA, Certificate Authority) -- "I (the CA) have verified this: this public key really does belong to this domain."

The OS and browser ship with a set of trusted root CA certificates pre-installed -- this is the starting point of the entire trust chain.

The certificate chain: verifying from the site's certificate all the way to the root

Production rarely has a root CA sign a website's certificate directly (a root certificate's private key is too precious to use casually) -- typically the root CA signs an intermediate certificate, and the intermediate certificate signs the site's leaf certificate.

After the browser gets the site's certificate, it must verify signatures along "leaf -> intermediate -> root", and only passes once it reaches a locally pre-installed root certificate -- if the intermediate certificate isn't fully configured, this chain breaks -- the most common pitfall in operations.

Key takeaways

• A public key alone can't prove ownership -- it needs a CA's signed backing
• Root CA certificates are pre-installed in the OS/browser, the starting point of the trust chain
• The certificate chain must verify to the root: leaf -> intermediate -> root -- missing the intermediate breaks the chain

Lesson 4 - What the TLS handshake is actually negotiating

Advanced · about 12 min

Goal: Cross-reference the packet simulation page and sort the 7 messages into three phases.

Phase 1: key exchange -- one round trip is all it takes

The client already includes its own ephemeral public key (key_share) in ClientHello, and the server includes its own in ServerHello -- each side uses "its own private key + the peer's public key" to compute the same shared secret (ECDHE), and this key itself is never transmitted over the network.

Phase 2: identity verification -- certificate + signature, both required

The server sends its certificate chain to prove "the public key is mine", then signs with its private key to prove "I really have the corresponding private key" -- only together do these two things constitute verified identity. The client locally verifies the certificate chain, domain match, and signature, and only sends back a Finished message once everything passes.

Phase 3: application data -- switching to symmetric encryption

The moment the handshake ends, both sides drop asymmetric encryption and switch entirely to the negotiated symmetric key to encrypt the actual HTTP requests and responses.

Key takeaways

• Phase 1 negotiates the key, phase 2 verifies identity, phase 3 is where data actually transfers
• The real symmetric key never appears on the network (forward secrecy)
• The certificate proves "whose public key", the signature proves "you really have the private key"

Lesson 5 - Version evolution: SSL -> TLS, 1.2 -> 1.3

Troubleshooting · about 10 min

Goal: Understand how these version names relate to each other, and why only 1.2/1.3 are recommended today.

SSL is TLS's predecessor

SSL 2.0 / 3.0 were found to have serious vulnerabilities long ago (3.0 had the famous POODLE attack) and have been disabled. In 1999 the IETF took over improving SSL 3.0 and renamed it TLS 1.0, which has since evolved all the way to today's TLS 1.3.

★ No legitimate website today is actually running the "SSL" protocol -- "SSL certificate" is just a naming convention carried over from history; what's actually running underneath is always TLS.

TLS 1.3 vs. 1.2: faster and more secure

Faster: 1.2's handshake needs 2 RTTs, 1.3 needs only 1 (the client includes key_share proactively).

More secure: 1.3 removed RSA key exchange (no forward secrecy) and several old cipher suites that had known issues directly from the protocol -- 1.3's cipher suite list is much shorter than 1.2's, because there are simply fewer algorithms to choose from, all of them relatively secure.

Hands-on: confirm a site has disabled old versions

Go to step (3) on the packet simulation page and try openssl s_client -connect domain:443 -tls1 for comparison -- a correctly configured site should reject the connection outright.

Key takeaways

• SSL is now a historical term -- what's actually running today is always TLS
• TLS 1.3 only needs 1 RTT, 1.2 needs 2
• Production should explicitly keep only TLS 1.2 / 1.3 and disable older versions