1 of 37

TCP, UDP, and TLS

CS 161 Fall 2021 - Lecture 29

Computer Science 161

Popa and Weaver

2 of 37

Announcements

Hybrid lectures in Lewis 100 continuing

Lectures will still be simulcast over Zoom and recorded for upload

Homework 5 due Friday, November 5th
Project 2 starter code released, final due date November 12th
Some office hours this week converted into design reviews

See Piazza for sign-up slots
See the website calendar for the updated office hours schedule

Computer Science 161

Popa and Weaver

3 of 37

Transmission Control Protocol (TCP)

Textbook Chapter 30

Computer Science 161

Popa and Weaver

4 of 37

TCP: 3-Way Handshake

Client chooses an initial sequence number x its bytes and sends a SYN (synchronize) packet to the server

Server chooses an initial sequence number y for its bytes and responds with a SYN-ACK packet

Client then returns with an ACK packet

Once both hosts have synchronized sequence numbers, the connection is “established”

Client

Server

SYN. Seq = x

SYN-ACK. Seq = y, Ack = x+1

ACK. Seq = x+1, Ack = y+1

Data

Computer Science 161

Popa and Weaver

5 of 37

TCP: Retransmission

If a packet is dropped (lost in transit):

The recipient will not send an ACK, so the sender will not receive the ACK
The sender repeatedly tries to send the packet again until it receives the ACK

If a packet is received, but the ACK is dropped:

The sender tries to send the packet again since it didn’t receive the ACK
The recipient ignores the duplicate data and sends the ACK again

When packets are dropped in TCP, TCP assumes that there is congestion and sends the data at a slower rate

Computer Science 161

Popa and Weaver

6 of 37

TCP: Ending/Aborting a Connection

To end a connection, one side sends a packet with the FIN (finish) flag set, which should then be acknowledged

This means “I will no longer be sending any more packets, but I will continue to receive packets”
Once the other side is no longer sending packets, it sends a packet with the FIN flag set

To abort a connection, one side sends a packet with the RST (reset) flag set

This means “I will no longer be sending nor receiving packets on this connection”
RST packets are not acknowledged since they usually mean that something went wrong

Computer Science 161

Popa and Weaver

7 of 37

TCP Flags

Indicator that the user is acknowledging the receipt of something (in the ack number)
Pretty much always set except the very first packet

Indicator of the beginning of the connection

One way to end the connection
Requires an acknowledgement
No longer sending packets, but will continue to receive

One way to end a connection
Does not require an acknowledgement
No longer sending or receiving packets

Computer Science 161

Popa and Weaver

8 of 37

TCP Packet Structure

Source Port (16 bits)		Destination Port (16 bits)
Sequence Number (32 bits)
Acknowledgement Number (32 bits)
Data Offset (4 bits)	Flags (12 bits)	Window Size (16 bits)
Checksum (16 bits)		Urgent Pointer (16 bits)
Options (variable length)
Data (variable length)

Computer Science 161

Popa and Weaver

9 of 37

TCP Attacks

TCP hijacking: Tampering with an existing session to modify or inject data into a connection

Data injection: Spoofing packets to inject malicious data into a connection

Need to know: The sender’s sequence number
Easy for MITM and on-path attackers, but off-path attackers must guess 32-bit sequence number (called blind injection/hijacking, considered difficult)
For on-path attackers, this becomes a race condition since they must beat the server’s legitimate response

RST injection: Spoofing a RST packet to forcibly terminate a connection

Same requirements as packet injection, so easy for on-path and MITM attackers, but hard for off-path attackers
Often used in censorship scenarios to block access to sites

Computer Science 161

Popa and Weaver

10 of 37

TCP Data Injection

Client

Server

ACK. Seq = x+1, Ack = y+1. Data, length A

ACK. Seq = y+1, Ack = x+1+A. Real data, length B

This packet will be ignored by the client since the client already processed the malicious packet!

Seq = y+1. Evil data, length B

Computer Science 161

Popa and Weaver

11 of 37

TCP Attacks

TCP spoofing: Spoofing a TCP connection to appear to come from another source IP address

Recall: IP packets can often be spoofed if the AS doesn’t block source addresses
Need to know: Sequence number in the server’s response SYN-ACK packet
Easy for MITM and on-path attackers, but off-path attackers must guess 32-bit sequence number (called blind spoofing, also considered difficult)
For on-path attackers, this is a race condition, since the real client will send a RST upon receiving the server’s SYN-ACK!

For an off-path attacker, TCP spoofing is often the basis of a "SYN flood" denial of service attack

When a server normally receives a SYN and generates a SYN-ACK it will allocate some memory
We will discuss SYN flood attacks in more detail later

Computer Science 161

Popa and Weaver

12 of 37

TCP Spoofing

Client

Server

RST. Seq = x+1

SYN-ACK. Seq = y, Ack = x+1

SYN. Seq = x

ACK. Seq = x+1, Ack = y+1. Evil data

An on-path attacker must send the evil data before the server receives the real client’s RST!

A MITM attack could just drop the client’s packets, however

Computer Science 161

Popa and Weaver

13 of 37

TCP Attacks

TCP provides no confidentiality or integrity

Instead, we rely on higher layers (like TLS, more on this next time) to prevent those kind of attacks

Defense against off-path attackers rely on choosing random sequence numbers

Bad randomness can lead to trivial off-path attacks: TCP sequence numbers used to be based on the system clock!

Computer Science 161

Popa and Weaver

14 of 37

User Datagram Protocol (UDP)

Textbook Chapter 30

Computer Science 161

Popa and Weaver

15 of 37

User Datagram Protocol (UDP)

Provides a datagram abstraction

A message, sent in a single layer 3 packet (though layer 3 could fragment the packet)
Max size limited by max size of packet

In reality, max size sometimes limited by size of L2 frame, since L3 fragmentation only works in 99% of the cases

Applications break their data into datagrams, which are sent and received as a single unit

Contrast with TCP, where the application can use a bytestream abstraction

No reliability or ordering guarantees, but adds ports

It still has best effort delivery

Much faster than TCP, since there is no 3-way handshake

Usually used by low-latency, high-speed applications where errors are okay (e.g. video streaming, games)

Computer Science 161

Popa and Weaver

16 of 37

UDP Attacks

No sequence numbers, so relatively easy to inject data into a connection or spoof connections

Higher layers must provide their own defenses against these attacks!

Computer Science 161

Popa and Weaver

17 of 37

UDP Packet Structure

UDP datagram header (not blue because this is so simple!)

Source Port (16 bits)	Destination Port (16 bits)
Length (16 bits)	Checksum (16 bits)
Data (variable length)

Computer Science 161

Popa and Weaver

18 of 37

Summary

Border Gateway Protocol (BGP): Routing packets

The Internet is made of smaller autonomous systems (AS)
Each AS broadcasts the shortest routes it knows of (dependent on the shortest routes of its neighbors and distance to neighbors)

Transmission Control Protocol (TCP): Reliably sending packets

3-way handshake: Client sends SYN, server sends SYN-ACK, client sends ACK
Provides reliability, ordering, and ports
Attack: TCP hijacking through data injection or RST injection

Blind attacks must guess the client’s or server’s sequence numbers

Attack: TCP spoofing by sending a spoofed SYN packet

Blind attacks must guess the server’s sequence number

User Datagram Protocol (UDP): Non-reliably sending packets

No reliability or ordering, only ports
Same injection and spoofing attacks as TCP, but easier

Computer Science 161

Popa and Weaver

19 of 37

TLS

Textbook Chapter 31

Computer Science 161

Popa and Weaver

20 of 37

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!

TLS

Transport

(Inter) Network

Link

Physical

4.5

Application

Computer Science 161

Popa and Weaver

21 of 37

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

Computer Science 161

Popa and Weaver

22 of 37

TLS Handshake

Textbook Chapter 31.1

Computer Science 161

Popa and Weaver

23 of 37

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

Client

Server

ServerHello

ClientHello

Computer Science 161

Popa and Weaver

24 of 37

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

Client

Server

ServerHello

ClientHello

Certificate

Computer Science 161

Popa and Weaver

25 of 37

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

Two approaches to sharing a premaster secret: RSA or Diffie-Hellman (DHE)

ServerHello

ClientHello

Client

Server

Certificate

Computer Science 161

Popa and Weaver

26 of 37

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)

ServerHello

ClientHello

Client

Server

Certificate

{PS}Kserver

Computer Science 161

Popa and Weaver

27 of 37

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

ServerHello

ClientHello

Client

Server

Certificate

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

g^b mod p

Computer Science 161

Popa and Weaver

28 of 37

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

Client

Server

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

g^b mod p

{PS}Kserver

Compute keys

Computer Science 161

Popa and Weaver

29 of 37

TLS Handshake Step 5: Exchange MACs

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

Recall MACs: Any tampering on the handshake will be detected
Not to be confused with MAC addresses

Client

Server

Compute keys

MAC(IB, steps 1-4)

MAC(IS, steps 1-4)

Computer Science 161

Popa and Weaver

30 of 37

TLS Handshake Step 6: Send Messages

Messages can now be sent securely

Encrypted and MAC’d
Note: TLS uses MAC-then-encrypt, even though encrypt-then-MAC is generally considered better, for legacy reasons

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

Popa and Weaver

31 of 37

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

RSA: The server decrypted the PS
DHE: The server signed 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)

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

Or RSA exchange

Computer Science 161

Popa and Weaver

32 of 37

TLS: Securing Messages

How can we be sure that network attackers can’t read or tamper with our messages?
The attacker doesn’t know PS

RSA: PS was encrypted with the server’s public key
DHE: An attacker cannot learn the Diffie-Hellman secret

The symmetric keys are derived from PS

The attacker doesn’t know the symmetric keys used to encrypt and MAC messages

Encryption and MACs provide confidentiality and integrity

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

Or RSA exchange

Computer Science 161

Popa and Weaver

33 of 37

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

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

Or RSA exchange

Computer Science 161

Popa and Weaver

34 of 37

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

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

Or RSA exchange

Computer Science 161

Popa and Weaver

35 of 37

Forward Secrecy

Textbook Chapter 31.1

Computer Science 161

Popa and Weaver

36 of 37

Forward Secrecy

Recall forward secrecy: If an attacker records a connection now and compromises secret values later, they cannot compromise the recorded connection
RSA TLS: No forward secrecy is guaranteed

The adversary can record RB, RS, and the encrypted PS
If the adversary later compromises the server’s private key, they can decrypt PS and derive the keys!

DHE TLS: Guaranteed forward secrecy

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 compromise 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

Computer Science 161

Popa and Weaver

37 of 37

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

Computer Science 161

Popa and Weaver