Lecture 14: SSL and HTTPS

What this lecture covers

This lecture moves from Kerberos to how the web secures network communication at internet scale using SSL/TLS and public-key cryptography. It first contrasts symmetric crypto (one shared key) with asymmetric crypto (separate public and private keys, plus signing and verification), then explains why Kerberos's single-KDC model doesn't scale to the web: a global key distribution center would need to be trusted by everyone, store keys for billions of users, and be online for every connection.

The second half of the lecture is about integrating cryptographic protection into an actual browser: protecting network data, protecting code and data running in the browser (the same-origin policy, cookies), and protecting the user interface (the lock icon). It covers certificate authorities, revocation, mixed content, insecure cookies, and the ForceHTTPS/HSTS mechanism. After watching, you should be able to explain how a certificate authority replaces a KDC, why mixed HTTP/HTTPS content is dangerous, and what HSTS actually prevents.

Key ideas

• Symmetric vs. asymmetric crypto: symmetric encryption uses one shared key for both encryption and decryption; asymmetric (public-key) crypto uses a public key to encrypt or verify and a separate private key to decrypt or sign.
• Getting rid of the online KDC: instead of a KDC generating and distributing session keys, a client can generate a random session key itself and encrypt it directly with the server's public key, removing the need for a trusted party to be online for every connection.
• Certificate authorities (CAs): a CA signs statements binding a principal's name to a public key; unlike a KDC, a CA does not need to be online for every transaction, since anyone can verify a signature offline.
• Certificates and revocation: certificates carry an expiration date to bound the damage from a leaked key, but revoking a certificate before expiration is unreliable in practice; certificate revocation lists (CRLs) and OCSP are both used but have real gaps, including latency and treating a down OCSP server as "fine."
• Same-origin separation for HTTPS: https:// and http:// URLs are different origins, and the host name in a URL must match the name in the presented certificate, or the browser should reject the connection.
• Mixed content / insecure embedding: loading scripts or other resources over plain HTTP inside an HTTPS page lets a network attacker inject malicious code that then runs with access to the page's secure cookies and origin.
• The secure cookie flag and its gap: a cookie without the secure flag can be sent over both HTTP and HTTPS, so an attacker who intercepts any HTTP request to a domain can steal cookies even if the site itself never serves plain HTTP.
• ForceHTTPS / HSTS: lets a site tell the browser to never accept HTTP for it, always reject bad certificates outright, and never load insecure content, closing the gap where users could otherwise click through certificate warnings.

Walkthrough

From Kerberos to public-key crypto (1:02)

The lecture reviews symmetric and asymmetric cryptographic primitives, then asks why the web doesn't just use Kerberos. Students identify the core problems: a single trusted KDC doesn't scale to a global user base, key management and account registration become unmanageable, and the KDC has to be online for every new connection, which is a performance and availability bottleneck.

Establishing keys without a KDC (8:08)

Using public-key crypto, a client that knows a server's public key can generate a random session key and encrypt it directly for the server, without any third party mediating the exchange. The lecture works through the resulting protocol's weaknesses (replay attacks, and the server having no way to authenticate the client), and describes fixes such as including a nonce from each side and having the client sign its message with its own key.

Certificate authorities and certificates (16:19)

This section introduces the certificate authority as the web's replacement for a KDC: a CA signs a statement binding a name to a public key, producing a certificate that anyone can verify offline using the CA's public key, which is hardcoded into browsers. Because certificates are typically valid for about a year rather than a few hours like Kerberos tickets, revocation becomes a real problem, covered through CRLs, OCSP, and the practice of browsers hardcoding known-bad certificates.

Integrating crypto into the browser (35:36)

The lecture identifies three things a browser must protect: data on the network (handled by TLS), code and data running in the browser (same-origin policy and cookies), and the user interface (the lock icon and URL bar). It explains how the https:// scheme creates a distinct origin from http://, why the certificate's host name must match the URL, and the historical quirk that a cookie's secure flag, not its origin, determines whether it is sent over HTTP as well as HTTPS.

Mixed content and cookie leaks (52:52)

Loading a script or other resource over plain HTTP from within an HTTPS page lets a network attacker substitute malicious content that then runs with the page's full privileges, including access to its secure cookies. The lecture also covers how an unmarked cookie can leak over an unrelated HTTP request (for example, one triggered by an attacker-controlled image tag), even if the real site never serves HTTP itself, and briefly introduces subresource integrity (checking a fetched resource against a known hash) as an alternative to requiring HTTPS for every embedded resource.

ForceHTTPS and HSTS (1:06:34)

The lecture closes with ForceHTTPS, the research proposal later standardized as HTTP Strict Transport Security (HSTS). A site that opts in gets three protections from the browser: certificate errors become fatal instead of dismissible, HTTP requests to the site are redirected to HTTPS before they ever leave the browser, and insecure content embedding is blocked. It discusses the bootstrapping problem (a browser cannot know a site wants HSTS the very first time it connects) and Chrome's practical workaround of shipping a hardcoded preload list of HSTS sites.

Before you watch

• Watch the previous lecture on Kerberos ("13. Network Protocols"), since this lecture explicitly compares SSL/TLS's certificate-based model to Kerberos's KDC-based model.
• Basic familiarity with encryption and digital signatures (covered earlier in this lecture) is assumed for the certificate discussion.

Check your understanding

1. Why doesn't a Kerberos-style KDC scale to securing the web, and how does a certificate authority avoid the same problems?
2. What must a browser verify about a server's certificate before trusting an HTTPS connection, and what can go wrong if a user is allowed to override certificate errors?
3. Explain how mixed content (loading an HTTP resource inside an HTTPS page) can let an attacker steal a user's secure cookies.
4. Why can a cookie without the secure flag be leaked even from a site that never serves plain HTTP itself?
5. What three protections does HSTS add for a site, and why doesn't it solve the very first connection to that site?