[tor-bugs] #32678 [Core Tor/Tor]: Exit relay DNS cache leaks information (was: Tor's DNS cache leaks information)

[Tor Bug Tracker & Wiki]

#32678: Exit relay DNS cache leaks information
--------------------------+------------------------
 Reporter:  mikeperry     |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------

Old description:

> In a soon-to-appear paper by Tobias Pulls and Rasmus Dahlberg, they
> discovered that it was possible to use Tor's Exit DNS cache to determine
> if a particular domain was accessed from that exit in the past hour.
>
> One option is to disable caching entirely. I'm not a fan of this
> approach.
>
> I think it is better for the cache to perform some kind of "hotness"
> threshold, where entries are stored in the cache as today, but not *used*
> from the cache until they are "hot" enough to no longer represent unique
> visits.. Something like N hits in T time. The edges of this threshhold
> would have to be randomized, to prevent an adversary from trivially
> keeping the cache on the edge of "hot" in order to probe it as it crosses
> over to hot by one visit..
>
> The cache in general should be more closely tied to TTL, IMO, so we can
> cache longer than an hour if a name supports it. It also should be given
> better OOM priority, so it is not trivial to flush by SENDME window
> filling attacks.
>
> Alex also suggested that we may just want to provide our own recursive
> resolver, properly sandboxed, so that people don't misconfigure DNS to
> cache in ways that are detectable, or use centralized DNS due to a
> system-wide default. Until then we should at least come up with some kind
> of official resolver conf recommendation. If Tor's cache is smart, it
> seems reasonable to instruct people to disable upstream DNS caching.

New description:

 In https://petsymposium.org/2020/files/papers/issue1/popets-2020-0013.pdf
 by Tobias Pulls and Rasmus Dahlberg, they describe that it is possible to
 use Tor's Exit DNS cache to determine if a particular domain was accessed
 from that exit in the past hour, and then use this information to
 eliminate website traffic fingerprinting false positives. This information
 leak might also be useful for other attacks.

 One option is to disable caching entirely. I'm not a fan of this approach.

 I think it is better for the cache to perform some kind of "hotness"
 threshold, where entries are stored in the cache as today, but not *used*
 from the cache until they are "hot" enough to no longer represent unique
 visits.. Something like N hits in T time. The edges of this threshhold
 would have to be randomized, to prevent an adversary from trivially
 keeping the cache on the edge of "hot" in order to probe it as it crosses
 over to hot by one visit..

 The cache in general should be more closely tied to TTL, IMO, so we can
 cache longer than an hour if a name supports it. It also should be given
 better OOM priority, so it is not trivial to flush by SENDME window
 filling attacks.

 Alex also suggested that we may just want to provide our own recursive
 resolver, properly sandboxed, so that people don't misconfigure DNS to
 cache in ways that are detectable, or use centralized DNS due to a system-
 wide default. Until then we should at least come up with some kind of
 official resolver conf recommendation. If Tor's cache is smart, it seems
 reasonable to instruct people to disable upstream DNS caching.

--

Comment (by mikeperry):

 Add link to paper; More specific bug title; Also +9000 for comment:3!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32678#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online