1 of 48

TLS

CS 161 Spring 2025 - Lecture 20

Computer Science 161

2 of 48

TLS

2

Textbook Chapter 31

Computer Science 161

3 of 48

TLS

TLS (Transport Layer Security): A protocol for creating a secure communication channel over the Internet

Replaces SSL (Secure Sockets Layer), which is an older version of the protocol

TLS is built on top of TCP

Relies upon: Byte stream abstraction between the client and the server
Provides: Byte stream abstraction between the client and the server

The abstraction appears the same to the end client, but TLS provides confidentiality and integrity!

3

TLS

Transport

(Inter) Network

Link

Physical

1

2

3

4

4.5

Application

7

Computer Science 161

4 of 48

Today: Secure Internet Communication with TLS

Goals of TLS

Confidentiality: Ensure that attackers cannot read your traffic
Integrity: Ensure that attackers cannot tamper with your traffic

Prevent replay attacks

The attacker records encrypted traffic and then replays it to the server
Example: Replaying a packet that sends “Pay $10 to Mallory”

Authenticity: Make sure you’re talking to the legitimate server

Defend against an attacker impersonating the server

4

Computer Science 161

5 of 48

TLS Handshake

5

Textbook Chapter 31

Computer Science 161

6 of 48

TLS Handshake Step 1: Exchange Hellos

Assume an underlying TCP connection has already been formed
The client sends ClientHello with

A 256-bit random number RB (“client random”)
A list of supported cryptographic algorithms

The server sends ServerHello with

A 256-bit random number RS (“server random”)
The algorithms to use (chosen from the client’s list)

RB and RS prevent replay attacks

RB and RS are randomly chosen for every handshake
This guarantees that two handshakes will never be exactly identical

6

Client

Server

ServerHello

ClientHello

Computer Science 161

7 of 48

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 validates the certificate

Verify 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 legitimate server (not an impersonator)
Recall: Certificates are public. Anyone can provide a certificate for anybody

7

Client

Server

ServerHello

ClientHello

Certificate

Computer Science 161

8 of 48

TLS Handshake Step 3: Premaster Secret

This step has two main purposes

Make sure the client is talking to the legitimate server (not an impersonator)

The server must prove that it owns the private key corresponding to the public key in the certificate

Give the client and server a shared secret

An attacker should not be able to learn the secret
This will help the client and the server secure messages later

8

ServerHello

ClientHello

Client

Server

Certificate

Computer Science 161

9 of 48

TLS Handshake Step 3: Premaster Secret (RSA)

The client randomly generates a premaster secret (PS)
The client encrypts PS with the server’s public key and sends it to the server

The client knows the server’s public key from the certificate

The server decrypts the premaster secret
The client and server now share a secret

Recall RSA encryption: Nobody except the legitimate server can decrypt the premaster secret
Proves that the server owns the private key (otherwise, it could not decrypt PS)

9

ServerHello

ClientHello

Client

Server

Certificate

{PS}Kserver

Computer Science 161

10 of 48

TLS Handshake Step 3: Premaster Secret (DHE)

The server generates a secret a and computes g^a mod p
The server signs g^a mod p with its private key and sends the message and signature
The client verifies the signature

Proves that the server owns the private key

The client generates a secret b and computes g^b mod p
The client and server now share a premaster secret: g^ab mod p

Recall Diffie-Hellman: an attacker cannot compute g^ab mod p

10

ServerHello

ClientHello

Client

Server

Certificate

{g^a mod p}K^-1server

g^b mod p

Computer Science 161

11 of 48

TLS Handshake Step 4: Derive Symmetric Keys

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

Usually derived by seeding a PRNG with the three values
Changing any of the values results in different symmetric keys

Four symmetric keys are derived

CB: For encrypting client-to-server messages
CS: For encrypting server-to-client messages
IB: For MACing client-to-server messages
IS: For MACing server-to-client messages
Note: Both client and server know all four keys

11

Client

Server

{g^a mod p}K^-1server

g^b mod p

Compute keys

Computer Science 161

30 min - 1:10

Now, we know (1) we are talking to the legitimate server and (2) we have a shared secret with the server
Remember that key reuse is bad -> we don’t want to reuse the same key for encrypting and MACing
This happens offline (no one is sending the keys, both client and server are just deriving the four symmetric keys)

Why four? We want to prevent reflection attacks - OOS (attacker takes client->server message and tries to replay it in the server->client direction)

Reflection will be rejected because the HMAC value is incorrect (it will be a HMAC computed with the wrong MAC key).

Security people are typically paranoid
Usually just bring this up because students ask why (but technically two keys would be valid in our course’s approach)
We’ll see that we don’t actually even worry about reflection attacks (since these are actually solved in a later step)

Both client and server know RB, RS, and PS (and they’re the only ones that know PS) -> they’re the only ones that can generate these keys!

Derived keys rely on randomness as well!

12 of 48

TLS Handshake Step 5: Exchange MACs

The server and client exchange MACs on all the messages of the handshake so far

Any tampering on the handshake will be detected thanks to the cryptographic MACs
Not to be confused with MAC addresses

12

Client

Server

Compute keys

MAC(IB, steps 1-4)

MAC(IS, steps 1-4)

Computer Science 161

13 of 48

TLS Handshake Step 6: Send Messages

Messages can now be sent securely

Encrypted and MAC’d

13

Client

Server

Compute keys

MAC(IB, steps 1-4)

MAC(IS, steps 1-4)

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

Computer Science 161

14 of 48

TLS: Talking to the Legitimate Server

How can we be sure 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 exchange

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

14

Client

Server

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

Certificate

{g^a mod p}K^-1server

g^b mod p

Computer Science 161

15 of 48

TLS: Replay Attacks

How can we be sure that the attacker hasn’t replayed old messages from a past TLS connection?
Every handshake uses a different RB and RS
The symmetric keys are derived from RB and RS

The symmetric keys are different for every connection

15

Client

Server

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

ClientHello

ServerHello

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

Computer Science 161

16 of 48

TLS: Replay Attacks

How can we be sure that the attacker hasn’t replayed old messages from the current TLS connection?
Add record numbers in the encrypted TLS message

Every message uses a unique record number
If the attacker replays a message, the record number will be repeated

TLS record numbers are not TCP sequence numbers

Record numbers are encrypted and used for security
Sequence numbers are unencrypted and used for correctness, in the layer below

16

Client

Server

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

Computer Science 161

17 of 48

Forward Secrecy

17

Textbook Chapter 31.1

Computer Science 161

18 of 48

Forward Secrecy

Forward secrecy: If an eavesdropper records an encrypted connection now and learns the secret values later, they cannot decrypt the recorded connection
TLS provides guaranteed forward secrecy, thanks to its use of DHE

Diffie-Hellman provides forward secrecy: PS is deleted after the TLS session is over, so the adversary can’t learn the keys, even if they later obtain the server’s private key
Note: Because the server’s Diffie-Hellman component is signed, the adversary can’t MITM the Diffie-Hellman exchange without the server’s private key

18

Computer Science 161

Diffie-Hellman itself guaranteed forward secrecy
Forward secrecy: Are you protected from the attacker (in the future) reading messages that they’ve written down in the past if they’ve now gained access to values?

This helps us decide between RSA and DHE

RSA: Attacker writes down RB, RS, and the encrypted PS -> if they later find out the server’s private key, they can decrypt PS and re-derive all the keys that have ever been used for the connections

Problem: Private keys are usually kept for a long time so if you encrypt using RSA, if the server’s private key is compromised, rip

DHE: Doesn’t rely on long-term secrets like RSA does! g^a mod p and g^b mod p don’t tell you what g^ab mod p is

Once we derive g^ab mod p, can destroy a and b (so even if Mallory hacked my laptop, she wouldn’t know what a and b were)
Then, once the session is over, g^ab mod p is also destroyed (and attackers have no hope in learning the symmetric keys for TLS)

19 of 48

TLS 1.3 Changes

TLS 1.3: The latest version of the TLS protocol (2018)
RSA no longer supported (only DHE)

Guarantees forward secrecy

Performance optimization: The client sends g^b mod p in ClientHello

If the server agrees to use DHE, the server sends g^a mod p (with signature) in ServerHello
Potentially saves two messages later in the handshake

Only supports AEAD mode encryption

Recall AEAD (authenticated encryption with additional data): a block cipher mode that guarantees confidentiality and integrity at the same time
Eliminates attacks associated with the insecure MAC-then-encrypt pattern

19

Computer Science 161

20 of 48

TLS in Practice

20

Textbook Chapter 31.3

Computer Science 161

21 of 48

TLS: Efficiency

Public-key cryptography: Minor costs

Client and server must perform Diffie-Hellman key exchange

Symmetric-key cryptography: Effectively free

Modern hardware has dedicated support for symmetric-key cryptography
Performance impact is negligible

Latency: Extra waiting time before the first message

Must perform the entire TLS handshake before sending the first message

21

Computer Science 161

22 of 48

TLS Provides End-to-End Security

TLS provides end-to-end security: Secure communication between the two endpoints, with no need to trust intermediaries

Even if everybody between the client and the server is malicious, TLS provides a secure communication channel -- secure against MITM, on-path attackers, and off-path attackers
End-to-end security does not help if one of the endpoints is malicious (e.g. communicating with a malicious server)
Example: An local network attacker (on-path) tries to read our Wi-Fi session, but can’t read TLS messages
Example: A man-in-the-middle tries to inject TCP packets, but packets will be rejected because the MAC won’t be correct

Using TLS defends against most lower-level network attacks

22

Computer Science 161

23 of 48

TLS Provides End-to-End Security (RSA)

23

Client

Man-in-the-middle

ClientHello

ServerHello

Certificate

Server

ClientHello

ServerHello

Certificate

{PS}Kserver

MITM cannot read PS since it’s encrypted with the server’s PK!

Computer Science 161

24 of 48

TLS Provides End-to-End Security

24

Client

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

Server

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

Man-in-the-middle

MITM cannot derive g^ab mod p due to the discrete log problem!

Computer Science 161

25 of 48

TLS Does Not Provide Anonymity

Anonymity: Hiding the client’s and server’s identities from attackers
An eavesdropper can figure out who is communicating

The certificate is sent during the TLS handshake, containing the server’s name
The client may also indicate the name of the server in the ClientHello (called Server Name Indication, or SNI)
An attacker can see IP addresses and ports of the underlying IP and TCP protocols

25

From: 20:61:84:3a:a9:52

To: 6d:36:ff:4a:32:92

From: 1.2.3.4

To: 5.6.7.8

From: Port 1234

To: Port 80

Encrypted TLS message,

MAC TLS tag

Information here is confidential!

Information here is not confidential!

Computer Science 161

26 of 48

TLS Does Not Provide Availability

Availability: Keeping the connection open in the face of attackers
An attacker can stop a TLS connection

MITM can drop encrypted TLS packets
On-path attacker can still do RST injection to abort the underlying TCP connection

Result: A TLS connection can still be censored

The censor can block TLS connections

26

From: Port 1234

To: Port 80

Encrypted TLS message,

MAC TLS tag

Encrypted TLS Information

Layer 4: TCP

Information here is secure!

Information here is not secure (no cryptography)!

TCP header

TCP data

Computer Science 161

27 of 48

TLS for Applications

Layering: TLS provides services to higher layers (the application layer)
HTTPS: The HTTP protocol run over TLS

In contrast, HTTP runs over plain TCP, with no TLS added

Other secure application-layer protocols besides HTTPS exist

Pretty much anything that runs over TCP can also run over TLS, since the bytestream abstraction is maintained
Example: Email protocol can use the STARTTLS command to uses TLS to secure communications

TLS does not defend against application-layer vulnerabilities

Example: SQL injection, XSS, CSRF, and buffer overflow vulnerabilities in the application are still exploitable over TLS

27

Computer Science 161

Our Networking unit (which started from the lowest layer) has actually hit our topmost layer, which intersects with our Web unit
Did anyone take 61c with Prof Dan Garcia, where he makes you do the conga when you finally learn the connection between hardware and software components?

We won’t make you do this (i mean your choice if you want to after class - i won’t stop you)

We can build anything over TLS since it guarantees we can send messages from one person to another with cryptographic guarantees
Remember in web, we were discussing abstractly, how you can send a message to someone else? Well, we just finished that–networking allows you to do this!
All HTTP needs is a way to send messages between computers -> you have that, it’s called TLS!
You can build ssh, file transfer protocols, etc -> a lot of different application layer protocols (we only require you to know HTTPS)
XSS:

I can create the most beautiful system with hardcore TLS, but in that encrypted TLS message that’s sent, there can be malicious Javascript that someone stored on my server… whelp
No one can tamper with the payload, but rip
TLS stops networking attacks at lower layers, not application-layer web vulnerabilities. It’s not a one-stop shop.

28 of 48

SSL Stripping Attacks

Browsers sometimes default to using unencrypted HTTP

If a user types google.com into the browser, the browser opens http://www.google.com
To mitigate this, websites will often redirect from the HTTP to the HTTPS version of its site
This requires the client to first receive the unprotected HTTP redirect response

SSL stripping: Forcing a user to use unencrypted HTTP instead of HTTPS

A MITM attacker intercepts the first HTTP request and creates their own HTTPS connection to the server
The user never receives a redirect to HTTPS, so it believes the site wants them to use HTTP
Defense: HTTP Strict-Transport-Security (HSTS) header tells browsers to only access the server with HTTPS

28

User

Attacker

Server

HTTP

HTTPS

Computer Science 161

29 of 48

TLS in Browsers

Original design:

When your browser communicates with a server over TLS, your browser displays a lock icon
If TLS is not used, there is no lock icon

What the lock icon means

Communication is encrypted (TLS guarantee)
You are talking to the legitimate server (TLS guarantee)
Any external images or scripts are also fetched over TLS

29

This website uses HTTP: no lock icon

This website uses HTTPS: lock icon

Computer Science 161

30 of 48

TLS in Browsers

What users think the lock icon means

This website is trustworthy, no matter where the lock icon actually appears

Attack: The attacker adds their own lock icon somewhere on the page

The user thinks they’re using TLS, but actually is not using TLS

Attack: The user might be communicating with an attacker’s website over TLS

The lock icon appears, but the user is actually vulnerable!

30

Computer Science 161

31 of 48

TLS in Browsers

Modern design: Add a “not secure” icon to connections that don’t use TLS

Adds a signal on unencrypted sites
Encourages websites to stop supporting all unencrypted, HTTP traffic and redirect to HTTPS

31

This website uses HTTP: insecure icon

This website uses HTTPS: lock icon

Computer Science 161

32 of 48

TLS Attack: PRNG Sabotage

Consider TLS with Diffie-Hellman

An attacker who learns the DHE secret a can derive the PS g^ab mod p (recall g^b mod p is sent over the channel), and then derive the symmetric keys (recall RC and RS are sent over the channel)

Consider using a PRNG to generate all random values

Includes the server DHE secret a and the client DHE secret b

What if the PRNG is sabotaged and doesn’t have rollback resistance?

Example of sabotage: Dual_EC DRBG with knowledge of the secret used to create the generator
Example of sabotage: ANSI X9.31: An AES-based PRNG with a secret key

Attack: See subsequent PRNG output and work backwards to learn the DHE secret

32

Computer Science 161

33 of 48

TLS Trust Issues: Certificate Authorities

33

Computer Science 161

34 of 48

Certificates in TLS

The server sends its certificate

Certificate: The server’s domain name and public key, signed by a certificate authority

The browser verifies the server’s certificate

The browser checks the domain name in the URL matches the domain name in the certificate
The certificate authority’s public key is hardwired into the browser (trust anchor)
The browser uses the CA’s public key to verify the signature

If the certificate is verified, the browser now knows the server’s public key

34

Computer Science 161

35 of 48

Issues: Unknown Certificate Authority

35

Computer Science 161

36 of 48

Issues: Unknown Certificate Authority

What if the browser doesn’t have the certificate authority’s public key for verification?
Warn the user that the website is not verified

The TLS connection can still proceed, but there is no guarantee that the user is talking to the legitimate server

What if the user is not talking to the legitimate server?

No more end-to-end security
An attacker can read and modify messages
An attacker can impersonate the server

36

Computer Science 161

37 of 48

Verifying Certificates

37

Computer Science 161

38 of 48

Issues: Revocation

What if an attacker steals a server’s private key?

The certificate with the corresponding public key is no longer valid
TLS certificates have an expiration date, but they often don’t expire for years

Solution: Certificate revocation lists

The CA occasionally sends out lists of certificates that are no longer valid
The browser occasionally downloads the lists

Solution: Online Certificate Status Protocol (OCSP)

The browser queries the CA whether a given certificate is still valid
The CA responds either “good” or “revoked,” signed with the CA’s private key

38

Computer Science 161

39 of 48

Issues: Trust Anchors

How many certificate authorities do we need to implicitly trust?

Modern browsers implicitly trust 100–200 root certificate authorities

A CA might issue a malicious certificate (e.g., stating that attacker’s public key belongs to Google) because:

The CA is hacked
An attacker pays the CA to issue a malicious certificate

39

Computer Science 161

40 of 48

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

40

	Link
Solo Iranian hacker takes credit for Comodo certificate attack
Gregg Keizer	March 27, 2011
Security researchers split on whether 'ComodoHacker' is the real deal A solo Iranian hacker on Saturday claimed responsibility for stealing multiple SSL certificates belonging to some of the Web's biggest sites, including Google, Microsoft, Skype and Yahoo. Early reaction from security experts was mixed, with some believing the hacker's claim, while others were dubious.

Computer Science 161

41 of 48

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

41

	Link
Fraudulent Google certificate points to Internet attack
Elinor Mills	August 29, 2011
Is Iran behind a fraudulent Google.com digital certificate? The situation is similar to one that happened in March in which spoofed certificates were traced back to Iran. A Dutch company appears to have issued a digital certificate for Google.com to someone other than Google, who may be using it to try to re-direct traffic of users based in Iran. Yesterday, someone reported on a Google support site that when attempting to log in to Gmail the browser issued a warning for the digital certificate used as proof that the site is legitimate, according to this thread on a Google support forum site.

Computer Science 161

42 of 48

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

42

	Link
Final Report on DigiNotar Hack Shows Total Compromise of CA Servers
Dennis Fisher	October 31, 2012
The attacker who penetrated the Dutch CA DigiNotar last year had complete control of all eight of the company’s certificate-issuing servers during the operation and he may also have issued some rogue certificates that have not yet been identified.

Computer Science 161

43 of 48

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

43

	Link
Evidence Suggests DigiNotar, Who Issued Fraudulent�Google Certificate, Was Hacked Years Ago
Mike Masnick	August 30, 2011
The big news in the security world, obviously, is the fact that a fraudulent Google certificate made its way out into the wild, apparently targeting internet users in Iran. The Dutch company DigiNotar has put out a statement saying that it discovered a breach back on July 19th during a security audit, and that fraudulent certificates were generated for "several dozen" websites. The only one known to have gotten out into the wild is the Google one.

Computer Science 161

44 of 48

Issues: Trust Anchors

DigiNotar: A certificate authority that was hacked

All web browsers removed DigiNotar from the list of trusted CAs

Takeaway: It is hard to implicitly trust the root CAs (trust anchors) in TLS
Takeaway: TLS CA ecosystem is largely secured through human relationships

CAs are motivated to be good because browser vendors can remove them from the list of trusted root CAs at any time (if they’ve been deemed to be bad)

44

Computer Science 161

45 of 48

Mitigating Trust Issues

Certificate pinning: The browser restricts which CAs are allowed to issue a certificate for each website

Example: Only Google's favorite CA is allowed to sign certificates for Google websites
Now creating a fake certificate for a specific website requires attacking a particular CA

Certificate transparency: Public logs provided by CAs

Specifics are out of scope
High-level idea: Use hash chains to keep a record of all issued certificates
The server can tell the browser to only accept certificates from CAs implementing transparency
If CA issues a bad certificate, this is detectable from the public logs

45

Computer Science 161

46 of 48

Certificate Authority Example: Let’s Encrypt

TLS requires every website to obtain and maintain certificates

Cost overhead: Certificates might cost money
Some management overhead involved

Let’s Encrypt: The world’s largest certificate authority

Issues certificates for free
Tries to make obtaining certificates as easy as possible

Steps of issuing a certificate (can all be automated with a script)

The server requests a certificate
Let’s Encrypt gives the server a file and tells the server to upload the file
The server uploads the file to the website
Let’s Encrypt verifies that the file has appeared on the website (thus verifying the server’s identity) and issues the certificate to the server

46

Computer Science 161

47 of 48

TLS: Summary

TLS Handshake

Nonces make every handshake different (prevents replay attacks across connections)
Certificate proves server’s public key
DHE proves that the server owns the private key
DHE helps client and server agree on a shared secret key
MACs ensure no one tampered with the handshake
Messages are sent with symmetric encryption and MACs
Record numbers prevent replay attacks within a connection

47

Client

Server

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

Computer Science 161

48 of 48

TLS: Summary

Security properties

Forward secrecy (thanks to DHE)
End-to-end security: Secure even if all intermediate hops are malicious
Not anonymous: Attackers can determine who you’re talking to
No availability: Connections can be dropped or censored

Can be used by the application layer (e.g., HTTPS)
Trusting certificate authorities can be hard

48

Computer Science 161