Re: [tor-bugs] #32678 [Core Tor/Tor]: Tor's DNS cache leaks information

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32678: Tor's 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:
--------------------------+------------------------
Description changed by mikeperry:

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 RTT, 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.

New 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 RTT, 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, perhaps 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.

--

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs