Encrypted DNS Privacy? A Traffic Analysis Perspective Sandra - - PowerPoint PPT Presentation

▶
encrypted dns privacy
SMART_READER_LITE
LIVE PREVIEW

Encrypted DNS Privacy? A Traffic Analysis Perspective Sandra - - PowerPoint PPT Presentation

Jul 07, 2023 115 likes •534 views

Encrypted DNS Privacy? A Traffic Analysis Perspective Sandra Siby, Marc Juarez, Claudia Diaz, Narseo Vallina-Rodriguez, Carmela Troncoso NDSS, 25 February 2020 Encrypted DNS > Privacy? Can encrypting DNS protect users from tra ffi

slide-1
SLIDE 1

NDSS, 25 February 2020

Encrypted DNS Privacy?

A Traffic Analysis Perspective

Sandra Siby, Marc Juarez, Claudia Diaz, Narseo Vallina-Rodriguez, Carmela Troncoso

slide-2
SLIDE 2

Encrypted DNS —> Privacy?

2

We conducted a number of experiments that show that:

  • Monitoring and censorship are feasible even when DNS is

encrypted.

  • Current proposed EDNS0-based countermeasures are not

sufficient to prevent traffic analysis attacks.

Can encrypting DNS protect users from traffic- analysis based monitoring and censoring?

slide-3
SLIDE 3

The Past

3

Recursive Resolver Client Name Servers Destination Host Query: google.com? Response: 172.217.168.4 google.com? g

  • g

l e . c

  • m

? google.com? HTTP requests and responses

172.217.168.4

slide-4
SLIDE 4

The Past

4

Recursive Resolver Client Name Servers Destination Host Query: google.com? Response: 172.217.168.4 google.com? g

  • g

l e . c

  • m

? google.com? HTTP requests and responses

Encrypted

172.217.168.4

slide-5
SLIDE 5

5

Recursive Resolver Client Name Servers Destination Host Query: google.com? Response: 172.217.168.4 google.com? g

  • g

l e . c

  • m

? google.com? HTTP requests and responses

Encrypted

172.217.168.4

The Past

slide-6
SLIDE 6

Encrypted DNS

6

Recursive Resolver Client Name Servers Destination Host Query: google.com? Response: 172.217.168.4 google.com? g

  • g

l e . c

  • m

? google.com? HTTP requests and responses

Encrypted

172.217.168.4

DNS-over-TLS (DoT) DNS-over-HTTPS (DoH)

slide-7
SLIDE 7

Encrypted DNS

7

Recursive Resolver Client Name Servers Destination Host Query: google.com? Response: 172.217.168.4 google.com? g

  • g

l e . c

  • m

? google.com? HTTP requests and responses

Encrypted

172.217.168.4

slide-8
SLIDE 8

Scenario

8

DNS-over-HTTPS traffic Adversary Goal: Determine webpage visited by the client from DNS-over-HTTPS traffic. Client Recursive Resolver

slide-9
SLIDE 9

Key Idea

9

A webpage visit can have multiple DNS queries/ responses associated with it, which could be a fingerprint for identification of that webpage.

slide-10
SLIDE 10

Scenario

10

DNS-over-HTTPS traffic Directionality

{

Timing Size Headers Adversary Client Recursive Resolver

slide-11
SLIDE 11

11

Training

DNS-over-HTTPS traffic Visit webpage

  • 1. Collect traces
  • 2. Extract traffic features
  • 3. Train model on features

Adversary Client Recursive Resolver

slide-12
SLIDE 12

12

Training

DNS-over-HTTPS traffic Visit webpage

  • 1. Collect traces
  • 2. Extract traffic features
  • 3. Train model on features

N-gram features Adversary Client Recursive Resolver

slide-13
SLIDE 13

13

Our experiment setup

Client Recursive Resolver DNS-over-HTTPS traffic Visit webpage

  • 1. Collect traces
  • 2. Extract traffic features
  • 3. Train model on features

Selenium +

Adversary

slide-14
SLIDE 14

14

Adversary Goal 1: Monitoring

Closed World Experiment

Set of webpages visited by user Set of webpages known to the adversary

Which particular webpage did the user visit?

slide-15
SLIDE 15

15

Adversary Goal 1: Monitoring

Closed World Experiment

Set of webpages visited by user Set of webpages known to the adversary

~90% Precision and Recall

1,500 pages

slide-16
SLIDE 16

16

Adversary Goal 1: Monitoring

Set of webpages visited by user Set of webpages monitored by adversary

Open World Experiment Did the user visit a page in the monitored set?

slide-17
SLIDE 17

17

Adversary Goal 1: Monitoring

Set of webpages visited by user Set of webpages monitored by adversary

Open World Experiment ~70% Precision and Recall

5,000 pages 50 pages

slide-18
SLIDE 18

Adversary Goal 2: Censorship

18

Censoring adversary: Identify webpages as fast as possible

Study the uniqueness of DoH traffic when only the first L TLS records have been observed (set of 5,000 pages).

slide-19
SLIDE 19

Adversary Goal 2: Censorship

19

Adversary strategy: Block on first query?

  • 4th record usually corresponds to first DoH query.
  • Blocking prevents user from loading the page.
  • Could result in high collateral damage — pages with same

domain name lengths are also blocked!

  • Iran: Blocking domain length = 13 blocks 97 domains in the

censored website list, but also blocks ~86,000 domains in the Alexa top 1M list

Censoring adversary: Identify webpages as fast as possible

slide-20
SLIDE 20

20

DNS-over-HTTPS traffic Visit webpage

Selenium +

Robustness of attack

Adversary’s training setup

What happens when any of the parameters in this setup change?

Adversary Client Recursive Resolver

slide-21
SLIDE 21

Robustness of attack: Parameters

21

Time (Dynamic Nature of websites) Location Infrastructure

  • Resolver
  • Client
  • Platform
slide-22
SLIDE 22

22

Robustness of attack: Results

  • Changes in scenario affect attack
  • Adversary needs classifier tailored to scenario for best results
slide-23
SLIDE 23

Countermeasures?

23

Monitoring and Censorship are feasible even when DNS traffic is encrypted. Website fingerprinting using DNS traces requires ~100 times less data than traditional website fingerprinting.

slide-24
SLIDE 24

EDNS0 Based Countermeasures

24

EDNS0: Extension mechanisms for DNS, specifies a padding option1

1RFC7830 2RFC8467

Padding of DNS queries: We implemented the recommended padding strategy2 on Cloudflare’s DoH client. Pad query to multiples

  • f 128 bytes.

Client Resolver

Query with padding Pad query

slide-25
SLIDE 25

EDNS0 Based Countermeasures

25

Padding of DNS responses: Cloudflare’s resolver pads responses to multiples of 128 bytes. Recommended strategy: Pad to multiples

  • f 468 bytes

Client Resolver

Response with padding Pad response

slide-26
SLIDE 26

Our experiments

26

EDNS0-128 EDNS0-468 Perfect Padding DNS over Tor Cloudflare’s response padding strategy Recommended response padding strategy Keep all TLS record sizes constant Cloudflare’s DNS over Tor service EDNS0-128-adblock User-side measure (ad-blocker usage)

slide-27
SLIDE 27

Results: Countermeasure comparison

27

0.001

90 70 45 34 7 3.5

slide-28
SLIDE 28

Results: DNS over Tor

28

0.001

90 70 45 34 7 3.5 Fixed cell sizes Repacketization

slide-29
SLIDE 29

Results: Overhead

29

Sent + received bytes (from TLS records)

slide-30
SLIDE 30

DNS-over-HTTPS (DoH) vs DNS-over-TLS (DoT)

30

Recursive Resolver Client Name Servers Destination Host Query: google.com? Response: 172.217.168.4 google.com? g

  • g

l e . c

  • m

? google.com? HTTP requests and responses

Encrypted

172.217.168.4

DNS-over-TLS (DoT) DNS-over-HTTPS (DoH)

slide-31
SLIDE 31

DNS-over-HTTPS (DoH) vs DNS-over-TLS (DoT)

31

We reran the classification process with DoT traffic Using DoT leads to ~40% Precision and Recall (compared to ~90% for DoH)

slide-32
SLIDE 32

DNS-over-HTTPS (DoH) vs DNS-over-TLS (DoT)

32

We reran the classification process with DoT traffic Using DoT leads to ~40% Precision and Recall (compared to ~90% for DoH) Does traffic variability account for better protection in DoT? DoT traffic looks different from DoH traffic

slide-33
SLIDE 33

Ongoing/Next Steps

33

Realistic scenarios

  • Data pollution (Multi-tab browsing, background apps)
  • Caching

Countermeasures

  • Padding + repacketization measures — Can we achieve

protection without using Tor?

slide-34
SLIDE 34

Summary

34

  • Surveillance and DNS-based censorship can occur even in the

presence of encrypted DNS.

  • Current proposed EDNS0 based countermeasures are not

sufficient.

  • Recommendation: Repacketization and padding

Code and datasets at: https://github.com/spring-epfl/doh_traffic_analysis Get in touch: sandra.siby@epfl.ch @sansib

slide-35
SLIDE 35

BACKUP

35

slide-36
SLIDE 36

Feature extraction

36

pcap file

24

  • 58

63 110 -92 -86 -55

TLS record sizes

24

  • 58

173

  • 233

Uni-grams: (24), (-58)…. Bi-grams: (24, -58), (-58, 63)… Uni-grams: (24), (-58)… Bi-grams: (24, -58), (-58, 173)… Burst sizes Single record sizes Counts

slide-37
SLIDE 37

Adversary Goal 2: Censorship

37

Censoring adversary: Identify webpages as fast as possible Consequences of blocking based on domain length Minimum collateral damage Maximum censor gain Most popular website Censor blocking strategy

slide-38
SLIDE 38

Adversary Goal 2: Censorship

38

Adversary strategy: High confidence guessing?

  • By 15th record (15% of trace), adversary can guess with high

confidence.

  • Less collateral damage.

Censoring adversary: Identify webpages as fast as possible

slide-39
SLIDE 39

DNS over Tor

39

Fixed cell sizes

  • Affect size features

Repacketization

  • Affect directionality

features

Confusion graph of misclassified labels

Pages in a cluster are misclassified as each other

Clusters in confusion graph?

slide-40
SLIDE 40

DNS-over-HTTPS (DoH) vs DNS-over-TLS (DoT)

40

DoT traffic looks different from DoH traffic:

  • Only DNS Type A records (compared to Type A and Type

AAAA in DoH)

  • Even after removal of AAAA traffic, smaller number of records

in DoT (more ‘bare-bones’ than DoH)

  • Larger record size in DoT

Does this traffic variability account for better protection in DoT?