TLS (continued)

CS 161 Fall 2021 - Lecture 30

Computer Science 161

Popa and Weaver

TLS in Practice

Textbook Chapter 31.3

2

Computer Science 161

Popa and Weaver

Last Time: TLS

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

3

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

Last Time: TLS

• Security properties
• DHE TLS: Forward secrecy
• RSA TLS: No forward secrecy
• End-to-end security: Secure even if all intermediate parties 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

4

Computer Science 161

Popa and Weaver

TLS: Efficiency

• Public-key cryptography: Minor costs
• Client and server must perform Diffie-Hellman key exchange or RSA encryption/decryption
• 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

5

Computer Science 161

Popa and Weaver

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

6

Computer Science 161

Popa and Weaver

TLS Does Not Provide Anonymity

• Anonymity: Hiding the client’s and server’s identities from attackers
• An attacker can figure out who is communicating with TLS
• 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

7

Computer Science 161

Popa and Weaver

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
• TLS 1.3 supports “Encrypted SNI”: The server’s name is requested after the key exchange itself
• But networks that want to enforce a lack of anonymity (censors, businesses, etc.) can recognize and terminate those connections

8

Computer Science 161

Popa and Weaver

TLS for Applications

• Recall Internet 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

9

Computer Science 161

Popa and Weaver

SSL Stripping Attacks

• Browsers often 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

10

User

Attacker

Server

HTTP

HTTPS

Computer Science 161

Popa and Weaver

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

11

This website uses HTTP: no lock icon

This website uses HTTPS: lock icon

Computer Science 161

Popa and Weaver

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!

12

Computer Science 161

Popa and Weaver

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

13

This website uses HTTP: insecure icon

This website uses HTTPS: lock icon

Computer Science 161

Popa and Weaver

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)
• An attacker who knows the PS can 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

14

Computer Science 161

Popa and Weaver

TLS Trust Issues: Certificate Authorities

15

But we can delegate…

Computer Science 161

Popa and Weaver

Recall: 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

16

Computer Science 161

Popa and Weaver

Issues: Unknown Certificate Authority

17

Computer Science 161

Popa and Weaver

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

18

Computer Science 161

Popa and Weaver

Verifying Certificates

19

Computer Science 161

Popa and Weaver

Verifying Certificates

20

Computer Science 161

Popa and Weaver

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

21

Computer Science 161

Popa and Weaver

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

22

Computer Science 161

Popa and Weaver

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

23

Computer Science 161

Popa and Weaver

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

24

Computer Science 161

Popa and Weaver

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

25

Computer Science 161

Popa and Weaver

Issues: Trust Anchors

Takeaway: Trust certificate authorities can be compromised by hackers

26

Computer Science 161

Popa and Weaver

Issues: Trust Anchors

• DigiNotar: A certificate authority that was hacked
• All web browsers removed DigiNotar from the list of trusted CAs
• WoSign: An untrustworthy certificate authority
• Also removed by all browsers
• A user who controls nweaver.github.com can create certificates for any subdomain of github.com
• Takeaway: It is hard to implicitly trust the root CAs (trust anchors) in TLS

27

Computer Science 161

Popa and Weaver

Solving Trust Issues

• Certificate pinning: The browser restricts which CAs are allowed to issue a certificate for each website
• Example: Only the Google 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
• The server can then make sure that a CA never screws up

28

Computer Science 161

Popa and Weaver

Solving Trust Issues

• Other solutions implementing to “trust but verify” the certificate you received
• EFF’s SSL Observatory: Check against certificates seen by other dedicated computers, called “observatories,” placed around the Internet
• ICSI’s Certificate Notary: Check against certificates used in common Internet traffic, by tapping into common Internet channels
• Specifics of these protocols are out of scope

29

Computer Science 161

Popa and Weaver

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:�Uses the ACME protocol to validate sites
• Certificates only last for a short period of time (forcing sites to automate renewing them)
• 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 at a specific location
• 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

30

Computer Science 161

Popa and Weaver

Using Let’s Encrypt in Go

• It is literally just a 2-liner to use Let's Encrypt with Go to turn an HTTP Go server into HTTPS:


import "golang.org/x/crypto/acme/autocert"

��...
� log.Fatal(http.Serve(autocert.NewListener("example.com"), handler))

• Takeaway: Enabling HTTPS in web servers today is often very simple!

31

Computer Science 161

Popa and Weaver

TLS Today

• Between Let’s Encrypt and browser changes, TLS is no longer something special
• It used to require a fair bit of effort and non-trivial money to set up!
• Instead, TLS is the default
• Biggest limitation with HTTPS:
• A page loaded over HTTPS can only include content from other HTTPS pages: no items from HTTP pages
• Advertisement networks were the biggest bottleneck in transitioning the web to almost universal support of HTTPS

32

Computer Science 161

Popa and Weaver

TLS: Summary

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

33

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

TLS: Summary

• Security properties
• DHE TLS: Forward secrecy
• RSA TLS: No forward secrecy
• End-to-end security: Secure even if all intermediate parties 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

34

Computer Science 161

Popa and Weaver

DNS

35

Computer Science 161

Popa and Weaver

Domain Names

• Recall: Computers are addressed by IP address on the Internet
• Example: 74.125.25.99
• Useful for machines: Can be used to route packets to the correct destination
• Not useful for humans: Numbers are not meaningful to humans, hard to remember
• More useful to humans: Human-readable domain names
• Example: www.google.com
• Not useful for machines: Contains no relevant routing information
• Useful for humans: Meaningful words and phrases, easy to remember
• Note: Domain names are not URLs. Domain names are part of a URL:�https://www.google.com/index.html

36

Computer Science 161

Popa and Weaver

DNS: Definition

• DNS (Domain Name System): An Internet protocol for translating human-readable domain names to IP addresses
• Usage
• You want to send a packet to a certain domain (e.g. you type a domain into your browser)
• Your computer performs a DNS lookup to translate the domain name to an IP address
• Your computer sends the packet to the corresponding IP address

37

74.125.25.99

www.google.com

DNS

Computer Science 161

Popa and Weaver

DNS Name Servers

• Name server: A server on the Internet responsible for answering DNS requests
• Name servers have domain names and IP addresses too
• Example: Domain a.edu-servers.net with IP 192.5.6.30 is a name server
• Usage:
• To perform a DNS lookup, your computer sends a DNS query (e.g. “What is the IP address of www.google.com?”)
• The name server sends a DNS response with the answer (e.g. “The IP address of www.google.com is 74.125.25.99”)
• Issues
• One name server won’t be able to handle every DNS request from the entire Internet
• If there are many name servers, how do you know which one to contact?

38

Computer Science 161

Popa and Weaver

DNS Name Server Hierarchy

• Idea #1: If one name server doesn’t know the answer to your query, the name server can direct you to another name server
• Analogy: If I don't know the answer to your question, I will direct you to a friend who can help
• Idea #2: Arrange the name servers in a tree hierarchy
• Intuition: Name servers will direct you down the tree until you receive the answer to your query

39

Computer Science 161

Popa and Weaver

DNS Name Server Hierarchy

40

Each box is a name server. The label represents which queries the name server is responsible for answering.

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

41

You

Let's walk through a DNS query for the IP address of eecs.berkeley.edu.

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

42

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

DNS queries always start with a request to the root name server, which is responsible for all requests.

“What is the IP address of eecs.berkeley.edu?”

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

43

You

The root name server responds by directing you to the correct child name server (in this case, the .edu name server).

“I don’t know, but I have delegated authority to the .edu name server.”

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

44

You

“What is the IP address of eecs.berkeley.edu?”

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

45

You

“I don’t know. But I have delegated authority to the berkeley.edu name server.”

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

46

You

“What is the IP address of eecs.berkeley.edu?”

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

47

You

“The IP address of eecs.berkeley.edu is 23.185.0.1.”

Computer Science 161

Popa and Weaver

Stub Resolvers and Recursive Resolvers

• In practice, your computer usually tells another resolver to perform the query for you
• Stub resolver: The resolver on your computer
• Only contacts the recursive resolver and receives the answer
• Recursive resolver: The resolver that makes the actual DNS queries
• Usually one recursive resolver per local network
• Benefits: The recursive resolver can cache common requests for the network

48

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

49

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

Recursive Resolver

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

50

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

The recursive resolver contacts all the name servers to answer the query, as we saw earlier.

Recursive Resolver

Computer Science 161

Popa and Weaver

Steps of a DNS Lookup

51

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

The recursive resolver returns the final answer to the stub resolver.

Recursive Resolver

Computer Science 161

Popa and Weaver

DNS Message Format

52

Computer Science 161

Popa and Weaver

DNS Uses UDP

• Recall UDP vs. TCP
• UDP: No delivery guarantees, packets can be reordered or dropped, faster
• TCP: Packets guaranteed to arrive in order, slower
• DNS is designed to be lightweight and fast
• Any access that involves a domain name (websites, email, etc.) is preceded by a DNS query, so we want DNS lookups to be fast
• DNS uses UDP instead of TCP for better performance
• No 3-way handshake!

53

Computer Science 161

Popa and Weaver

DNS Packet Format: UDP Header

• Source port (16 bits): Chosen by the client
• Can be randomized for security, as we’ll see later
• Destination port (16 bits): Usually 53
• DNS name servers answer requests on Port 53
• Checksum: Code to check the UDP payload was not corrupted in transit
• You don’t need to worry about this
• Length: Length of the UDP payload
• You don’t need to worry about this

54

UDP Payload

UDP Header

Computer Science 161

Popa and Weaver

DNS Packet Format: DNS Payload

• ID number (16 bits): Used to associate queries with responses
• Client picks an ID number in the query
• Name server uses the same ID number in the response
• Should be random for security, as we’ll see later
• Counts: The number of records of each type in the DNS payload

55

DNS Payload

UDP Header

DNS Header

Computer Science 161

Popa and Weaver

DNS Packet Format: DNS Header

• The DNS payload contains a variable number of resource records (RRs)
• Each RR is a name-value pair
• RRs are sorted into four sections
• Question section
• Answer section
• Authority section
• Additional section

56

DNS Payload

UDP Header

DNS Header

Computer Science 161

Popa and Weaver

DNS Record Format

• Each record is a name-value pair with a type
• A (answer) type records: Maps a domain name to an IPv4 address
• NS (name server) type records: Designates another DNS server to handle a domain
• Other types exist, but these are the two you need to know for now
• Each record also contains some metadata
• Time to live (TTL): How long the record can be cached
• Other metadata fields exist, but you don’t need to worry about them
• All records of {name, type} pair form an RRSET, a group of records that should have the same TTL

57

Computer Science 161

Popa and Weaver

DNS Record Types

• Other record types you might encounter:
• AAAA type record: Maps a domain name to an IPv6 address
• CNAME type record: Maps one domain name to another domain name. Used for aliases.
• MX type record: Used for mail servers
• SOA: Contains information about the operator/administrator of a zone
• Other types for text records, cryptographic information, etc. exist too
• You don’t need to know about any of these

58

Computer Science 161

Popa and Weaver

DNS Record Sections

• Question section: What is being asked
• Included in both requests and responses
• Usually an A type record with the domain being looked up
• Answer section: A direct response to the question
• Empty in requests
• Used if the name server responds with the answer
• Usually an A type record with the IP address of the domain being looked up
• Authority section: A delegation of authority for the question
• Empty in requests
• Used to direct the resolver to the next name server
• Usually an NS type record with the zone and domain of the child name server
• Additional:

59

Computer Science 161

Popa and Weaver

DNS Record Sections

• Additional section: Additional information to help with the response, sometimes called glue records
• Empty in requests
• Provides helpful, non-authoritative records for domains
• Usually an A type record with the domain and IP address of the child name server (since the NS record provides the child name server as a domain)

60

Computer Science 161

Popa and Weaver

DNS Record Caching

• For performance, resolvers cache as many records as possible
• Records returned by name servers are cached until their time-to-live expires
• No DNS requests need to be sent for recently-seen queries
• Makes response time faster for clients
• Reduces load on name servers

61

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

62

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

63

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

64

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

​

65

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

66

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

​

67

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

68

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

69

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

70

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

71

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

72

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

73

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

​

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

74

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @192.5.6.30

75

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @192.5.6.30

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36257

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; AUTHORITY SECTION:

berkeley.edu. 172800 IN NS adns1.berkeley.edu.

berkeley.edu. 172800 IN NS adns2.berkeley.edu.

berkeley.edu. 172800 IN NS adns3.berkeley.edu.

​

;; ADDITIONAL SECTION:

adns1.berkeley.edu. 172800 IN A 128.32.136.3

adns2.berkeley.edu. 172800 IN A 128.32.136.14

adns3.berkeley.edu. 172800 IN A 192.107.102.142

...

76

The answer section is blank again. The authority and additional section tell us to query a berkeley.edu name server, and provide us with the IP address of the next name server.

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

77

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52788

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1

78

Computer Science 161

Popa and Weaver

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52788

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1

79

Computer Science 161

Popa and Weaver

DNS Security

80

Break: Back at 4:38 PM PT

Computer Science 161

Popa and Weaver

Cache Poisoning Attacks

• Cache poisoning attack: Returning a malicious record to the client
• The victim will cache the malicious records, “poisoning” it
• Example: Supply a malicious A record mapping the attacker’s IP address to a legitimate domain
• Now when the victim visits eecs.berkeley.edu, they’ll actually be sending packets to the attacker (6.6.6.6), who can act as a MITM!

81

Computer Science 161

Popa and Weaver

Security Risk: Malicious Name Servers

• Malicious name servers can lie and supply a malicious answer
• Malicious records could also poison the cache with other records

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

​

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52788

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

​

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

​

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1

​

;; ADDITIONAL SECTION:

www.google.com. 172800 IN A 6.6.6.6

82

Computer Science 161

Popa and Weaver

Defense: Bailiwick Checking

• Idea: Limit the amount of damage a malicious name server can do
• Bailiwick checking: the resolver only accepts records if they are in the name server’s zone
• Bailiwick: “one’s sphere of operations or particular area of interest”
• Example: The berkeley.edu name server can provide a record for eecs.berkeley.edu, but not mit.edu
• Example: The .edu name server can provide a record for mit.edu and berkeley.edu, but not google.com
• Example: The root name server can provide a record for any domain (everything is in bailiwick for the root)

83

Computer Science 161

Popa and Weaver

Security Risk: Man-in-the-middle (MITM) Attackers

• DNS is not secure against MITM attackers
• MITM attackers can poison the cache by adding, removing, or changing any record in the DNS response

84

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1 6.6.6.6

Computer Science 161

Popa and Weaver

Security Risk: On-Path Attackers

• DNS is not secure against on-path attackers
• On-path attackers can poison the cache by sending a spoofed response
• If the spoofed response arrives before the legitimate response, the victim will cache the attacker’s malicious records
• The on-path attacker can see every field in the unencrypted DNS request. Nothing to guess!

85

Computer Science 161

Popa and Weaver

Security Risk: Off-Path Attackers

• The off-path attacker needs to guess the ID field to spoof a response
• If the ID in the response doesn’t match the ID in the request, the resolver won’t accept the response
• If the ID number is randomly generated:
• Probability of guessing correctly = 1/2¹⁶
• Recall: The ID number is 16 bits long
• Requires approximately 65,000 tries to successfully send a spoofed packet
• This is too small!

86

DNS Payload

UDP Header

DNS Header

Computer Science 161

Popa and Weaver

Security Risk: Off-Path Attackers

• What if the ID field is incremented by 1 for every request?
• Off-path attacker can spoof a packet as follows:
• Trick the victim into visiting the attacker’s website
• Include this HTML on the attacker’s website: <img src="http://www.attacker.com">
• The victim’s browser will make a DNS query for www.attacker.com
• If the attacker controls the attacker.com DNS name server, they can see the request and learn the ID field
• Include this HTML on the attacker’s website: <img src="http://www.google.com">
• The victim’s browser will make a DNS query for www.google.com
• The attacker knows the ID is 1 more than the previous ID, so they can spoof a response!
• ID numbers need to be random in DNS requests

87

Computer Science 161

Popa and Weaver

Kaminsky Attack

• Notice: If the attacker places <img src="http://www.google.com"> multiple times on their website, the browser will only make 1 DNS query
• The browser caches address of www.google.com
• The attacker only gets one try
• Dan Kaminsky, security researcher, noticed that DNS clients would cache additional glue records as if they were authoritative answers, even though they aren’t

88

Computer Science 161

Popa and Weaver

Kaminsky Attack

• Now, the attacker can gain more tries at once:
• The attacker includes
• <img src="http://fake1.google.com">
• <img src="http://fake2.google.com">
• <img src="http://fake3.google.com">
• <img src="http://fake4.google.com">
• For each, the client makes a request for the domain name
• The attacker’s spoofed response contains:
• Authority: fake1.google.com. 172800 IN NS www.google.com.
• Additional: www.google.com. 172800 IN A 6.6.6.6
• The client now caches the record for www.google.com, and the cache is poisoned!

89

Computer Science 161

Popa and Weaver

Defense: Source Port Randomization

• Randomize the source port of the DNS query
• The attacker must guess the destination port of the response in addition to the query ID
• This adds 32 bits to guess, to total 2⁴⁸ possibilities
• Other ways to increase entropy:
• Randomly capitalize the domain, since the question is copied in the response

90

90

DNS Payload

UDP Header

DNS Header

Computer Science 161

Popa and Weaver

Defense: Glue Validation

• Don’t cache glue records as part of DNS lookups
• They are necessary, since NS records are given in terms of domain names, not IP addresses
• If you want to cache, you can perform a separate recursive DNS lookup to validate the glue record authoritatively
• Issue: This was not implemented by all DNS software
• Unbound, a major DNS implementation, implemented validation
• BIND, the oldest and most common implementation, did not
• Mainly for political reasons: They supported DNSSEC, which uses cryptography to validate DNS records (we’ll look at this next time)

91

Computer Science 161

Popa and Weaver

Profiting from DNS Attacks

• Suppose you take over a lot of home routers… How do you make money from your attack?
• Change the DNS server settings
• Each router is programmed with the IP address of the recursive resolver
• Replace the IP address of the recursive resolver with the attacker’s IP address
• Cache poisoning attacks are now possible!
• Redirect all DNS requests for ads to an attacker-controlled domain and serve attacker-chosen ads to the victim
• The attacker can now sell this advertising space!
• TLS can defend against this (recall: end-to-end security)

92

Computer Science 161

Popa and Weaver

DNS: Summary

• DNS (Domain Name System): An Internet protocol for translating human-readable domain names to IP addresses
• DNS name servers on the Internet provide answers to DNS queries
• Name servers are arranged in a domain hierarchy tree
• Lookups proceed down the domain tree: name servers will direct you down the tree until you receive an answer
• The stub resolver tells the recursive resolver to perform the lookup

93

. (root)

.edu

.org

.com

google.com

piazza.com

cs161.org

mit.edu

berkeley.edu

Computer Science 161

Popa and Weaver

DNS: Summary

• DNS message structure
• DNS uses UDP for efficiency
• DNS packets include a random 16-bit ID field to match requests to responses
• Data is encoded in records, which are name-value pairs with a type
• A (answer) type records: Maps a domain name to an IPv4 address
• NS (name server) type records: Designates another DNS server to handle a domain
• Records are separated into four sections
• Question: Contains query
• Answer: Contains direct answer to query
• Authority: Directs the resolver to the next name server
• Additional: Provides extra information (e.g. the location of the next name server)
• Resolvers cache as many records as possible (until their time-to-live expires)

94

Computer Science 161

Popa and Weaver

DNS Security: Summary

• Cache poisoning attack: Send a malicious record to the resolver, which caches the record
• Causes packets to be sent to the wrong place (e.g. to the attacker, who becomes a MITM)
• Risk: Malicious name servers
• Defense: Bailiwick checking: Resolver only accepts records in the name server’s zone
• Risk: Network attackers
• MITM attackers can poison the cache without detection
• On-path attackers can race the legitimate response to poison the cache
• Off-path attackers must guess the ID field (Defense: Make the ID field random)
• Kaminsky attack: Query non-existent domains and put the poisoned record in the additional section (which will still be cached). Lets the off-path attacker try repeatedly until succeeding
• Defense: Source port randomization (more bits for the off-path attacker to guess)

95

Computer Science 161

Popa and Weaver