1 of 30

1

CS 161, Summer 2026 @ UC Berkeley

Slides credit: Nick Weaver, Nicholas Ngai, Peyrin Kao, Henry Corrigan-Gibbs, Jonah Bedouch

TLS

Lecture 17 (Transport 5)

2 of 30

Layer 4.5

Lecture 17, CS 161, Summer 2026

TLS

  • Layer 4.5
  • Handshake
  • Security Goals
  • Legacy Designs
  • Certificates
  • Using TLS

3 of 30

TLS at Layer 4.5

Recall: Many attacks exist at lower layers.

TLS (Transport Layer Security) is a protocol for secure communication on top of those layers.

​

TLS is built on top of TCP (Layer 4).

  • Relies on TCP's bytestream abstraction.

​

TLS provides security to Layer 7 applications.

  • Provides a bytestream abstraction, but with extra security.
  • Because the abstraction is the same, any application that runs over TCP can run over TLS.

Physical

Data Link

Network

Transport

Secure Transport

4.5

4

3

2

1

(TLS, SSL)

(TCP, UDP)

(IP)

(Ethernet)

(Optical fiber, copper)

Application

7

(DNS, HTTP)

SSL was an older version of the protocol.

TLS is labeled 4.5 because 5 and 6 already exist (and are now obsolete).

4 of 30

Goals of TLS

Confidentiality: Ensure that attackers cannot read your traffic.

​

Integrity: Ensure that attackers cannot tamper with your traffic.

  • Prevent replay attacks, where the attacker records encrypted traffic and then replays it.

​

Authentication: Ensure that the user is talking to the legitimate website.

  • Prevent the attacker from impersonating the server.

5 of 30

TLS Handshake

Lecture 17, CS 161, Summer 2026

TLS

  • Layer 4.5
  • Handshake
  • Security Goals
  • Legacy Designs
  • Certificates
  • Using TLS

6 of 30

TLS Handshake Step 1: Exchange Hellos

An underlying TCP connection has already been formed, so we can use the bytestream abstraction.

​

The client sends ClientHello with:

  • A 256-bit random number RC.
  • A list of supported crypto algorithms.

​

The server sends ServerHello with:

  • A 256-bit random number RS.
  • The algorithms to use (chosen from client's list).

​

RC and RS are randomly chosen for every handshake.

  • Ensures that handshakes will never be identical.

Client

Server

ClientHello

ServerHello

7 of 30

TLS Handshake Step 2: Certificate

The server sends its certificate.

  • Recall certificates: The server's identity and public key, signed by a trusted certificate authority.

​

The client verifies the signature in the certificate.

  • The client now knows the server's public key.
  • The client is not yet sure that they are talking to the real server.
  • Recall: Certificates are public. Anyone can provide a certificate for anybody.

Client

Server

ClientHello

ServerHello

Certificate

8 of 30

TLS Handshake Step 3: Premaster Secret

The server and client derive a shared secret called the premaster secret (PS).

  • Recall Diffie-Hellman key exchange: Both sides derive gab mod p, but nobody else can derive it.

​

The server signs its half of the key exchange, sending both ga mod p and the signature.

  • Allows the server to prove that it owns the private key corresponding to the public key in the certificate.
  • The client verifies the signature, and is now confident they are talking to the real server.

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

9 of 30

TLS Handshake Step 4: Derive Symmetric Keys

The server and client each derive symmetric keys from RC, RS, and PS.

  • Multiple keys can be derived to avoid key reuse.
  • Derivation happens offline (no data is sent).

​

The keys are derived with a pseudorandom function.

  • Recall: PRFs are deterministic, so the two sides will derive the same keys.
  • Recall: PRF output is hard to predict for attackers who don't know the inputs (e.g. PS).

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

Derive keys

Derive keys

10 of 30

TLS Handshake Step 5: Exchange MACs

The client sends a MAC on all the messages sent/received in the handshake so far.

  • The MAC is computed with a symmetric key that both sides know.
  • The server verifies the MAC, using the same key.

​

Similarly, the server sends a MAC on all messages so far, and the client verifies it.

​

Any tampering on the earlier handshake steps will be detected here.

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

Derive keys

Derive keys

MAC(KS, steps 1–4)

MAC(KC, steps 1–4)

11 of 30

TLS Handshake Step 6: Send Messages

The client and server can now securely exchange messages.

​

Data is secured with an AEAD (authenticated encryption with additional data) scheme,�e.g. AES-GCM.

​

Each message has a unique record number to prevent replay attacks.

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

Derive keys

Derive keys

MAC(KS, steps 1–4)

MAC(KC, steps 1–4)

AES-GCM(KS, data2)

AES-GCM(KC, data1)

12 of 30

TLS Security Goals

Lecture 17, CS 161, Summer 2026

TLS

  • Layer 4.5
  • Handshake
  • Security Goals
  • Legacy Designs
  • Certificates
  • Using TLS

13 of 30

TLS Security Goals: Talking to the Legitimate Server

How can we be sure that we are talking to the legitimate server?

  • The server sent its certificate, so we know the server's public key.
  • The server proved that it owns the corresponding private key by signing its half of the key exchange.

​

An attacker impersonating the server would not have the server's private key (assuming they have not compromised the server).

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

Derive keys

Derive keys

MAC(KS, steps 1–4)

MAC(KC, steps 1–4)

AES-GCM(KS, data2)

AES-GCM(KC, data1)

14 of 30

TLS Security Goals: Replay Attacks

Preventing replays from past connections:

  • Every handshake uses a different RC, RS.
  • The symmetric keys are derived from RC, RS.
  • Since the keys are different in every connection, replays will fail.

​

Preventing replays from current connection:

  • Every message has a unique record number.
  • Replays will have duplicate record numbers and be discarded.
  • Note: TLS record numbers (encrypted, for security) are different from TCP sequence numbers (unencrypted, for correctness).

MAC(KS, steps 1–4)

MAC(KC, steps 1–4)

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

AES-GCM(KS, data2)

AES-GCM(KC, data1)

Derive keys

Derive keys

15 of 30

Legacy Designs

Lecture 17, CS 161, Summer 2026

TLS

  • Layer 4.5
  • Handshake
  • Security Goals
  • Legacy Designs
  • Certificates
  • Using TLS

16 of 30

TLS 1.3 Changes

TLS 1.3 (2018) is the latest version of the protocol.

​

Security upgrade: Removed support for weaker, insecure algorithms.

  • Removing options also makes TLS itself simpler:�less code, fewer edge cases, fewer opportunities for bugs.

​

Performance upgrade: Rearranged steps to allow the handshake to finish faster.

17 of 30

Legacy Premaster Secret Scheme: RSA

The server proves its identity by decrypting the premaster secret.

The shared secret is PS (directly chosen by the client, secured with RSA).

Older versions of TLS used RSA encryption instead of Diffie-Hellman key exchange.

Client generates Premaster Secret (PS), and encrypts it with server's public key.

The server proves its identity by signing its half of the key exchange.

The shared secret is PS = gab mod p (secured with DHE).

Client

Server

ga mod p, signed by SKserver

gb mod p

Client

Server

Enc(PKserver, PS)

DHE (modern)

RSA (legacy)

18 of 30

Forward Secrecy

Recall forward secrecy: If an eavesdropper records an encrypted connection now and learns the secret values later, they cannot decrypt the recorded connection.

Does not provide forward secrecy: Attacker can steal SKserver later and use it to decrypt the recorded PS.

Provides forward secrecy: a, b, PS discarded after each connection.

Values sent during handshake cannot be used to re-derive PS.

Client

Server

ga mod p, signed by SKserver

gb mod p

Client

Server

Enc(PKserver, PS)

DHE (modern)

RSA (legacy)

19 of 30

Optimizing Handshake

Rearranging the steps allows the handshake to complete in one fewer round-trip.

Client must guess which algorithm the server will choose before seeing ServerHello.

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

MAC(KS, steps 1–4)

MAC(KC, steps 1–4)

Client

Server

ClientHello

ServerHello

Certificate

ga mod p, signed by SKserver

gb mod p

MAC(KS, steps 1–4)

MAC(KC, steps 1–4)

Old: 2 round-trips

New: 1 round-trip

AES-GCM(KC, data1)

AES-GCM(KC, data1)

1

2

1

Client can send data1 alongside its MAC of handshake.

20 of 30

TLS Certificates

Lecture 17, CS 161, Summer 2026

TLS

  • Layer 4.5
  • Handshake
  • Security Goals
  • Legacy Designs
  • Certificates
  • Using TLS

21 of 30

Public-Key Infrastructure

One tricky question: Who signs certificates for the servers?

​

Recall: Certificates require trusting root certificate authorities (root CAs).

  • The Internet has about 150 root CAs, run by real-world businesses and organizations that we hope are trustworthy.
  • Browsers come with pre-installed lists of root CAs.

22 of 30

Unknown Certificate Authority

23 of 30

Using TLS

Lecture 17, CS 161, Summer 2026

TLS

  • Layer 4.5
  • Handshake
  • Security Goals
  • Legacy Designs
  • Certificates
  • Using TLS

24 of 30

TLS Stops Lower-Level Attacks

TLS defends against many lower-level network attacks.

  • An attacker could become a MITM (e.g. through ARP spoofing), but still cannot read or modify messages in a TLS connection.

​

Applications can run on TLS-over-TCP, or on plain TCP.

  • Both provide bytestream abstractions.
  • Example: HTTPS uses TLS-over-TCP, while HTTP uses plain TCP.
  • Example: Email can be secured with TLS.

25 of 30

Encouraging TLS Use: Browsers and CAs

On the web, HTTPS (over TLS) only offers security if websites actually use it.

  • Websites might stick with old HTTP, out of laziness.

​

To encourage more HTTPS adoption, browsers show warnings or refuse to load HTTP websites.

​

​

​

In 2015, Let's Encrypt (now the world's largest CA) started offering free certificates, to further incentivize HTTPS adoption.

If a website doesn't support HTTPS, browsers often show a "Not Secure" warning to the user.

26 of 30

Encouraging TLS Use: HSTS

HTTP Strict Transport Security (HSTS) is an HTTP response from servers that says:�"I don't accept plain HTTP requests, only HTTPS ones."

A client seeing this response is redirected to using HTTPS.

Client

Server

GET http://www.google.com

Nope. Ask for https://www.google.com instead.

27 of 30

Encouraging TLS Use: Downgrade Attacks

SSL Stripping: Trick the user into using plain HTTP, by blocking the HSTS redirect.

  1. User makes a plain HTTP request.
  2. MITM intercepts the request, and copies it in their own HTTPS request�(impersonating the user).
  3. MITM gets an HTTPS response.
  4. MITM copies the response as plain HTTP, and sends it back to the user.

Client

Server

GET http://www.google.com

Secure HTTPS response

MITM Attacker

Plain HTTP response

GET https://www.google.com

28 of 30

Encouraging TLS Use: Preventing Downgrade Attacks

SSL Stripping is a downgrade attack: User is tricked into using older, insecure code.

Defenses: Minimize the use of plain HTTP.

  • Make the browser default all requests to HTTPS.
  • Make sure all links on websites start with https:// and not http://.

Client

Server

GET http://www.google.com

Secure HTTPS response

MITM Attacker

Plain HTTP response

GET https://www.google.com

29 of 30

TLS Adoption Over Time

30 of 30

The End...or Not?

TLS sounds great – everyone between our browser and the website can be a MITM, and they still can't interfere with our connection.

​

What's the catch?

  • Come back next time to find out what TLS doesn't provide.