Opened 11 months ago

Last modified 11 months ago

#32678 new defect

Exit relay DNS cache leaks information

Reported by: mikeperry Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal? backport?
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

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.

Child Tickets

Change History (6)

comment:1 Changed 11 months ago by mikeperry

Description: modified (diff)

comment:2 Changed 11 months ago by mikeperry

Description: modified (diff)

comment:3 Changed 11 months ago by pulls

The hotness threshold sounds like a great idea. It should be randomized in such a way that an attacker cannot predict the threshold for a given entry in the cache at the time it gets added to the cache. If all entries in a cache share the same threshold, then it's trivial for the attacker to probe this using a domain it controls. If the threshold does not change each time the same domain is added to the cache at a relay, then the attacker can probe it as well. (I guess this is what was meant above, just spelling it out.)

Another issue is if an attacker can detect when a entry expires from the cache. If the TTL calculation is deterministic, like now set to one hour, it tells you when the entry was visited at the exit. Probably want to randomize this as well in the order of at least a few minutes (up, never down).

comment:4 Changed 11 months ago by mikeperry

Description: modified (diff)
Summary: Tor's DNS cache leaks informationExit relay DNS cache leaks information

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

comment:5 Changed 11 months ago by nickm

Keywords: needs-proposal? added
Milestone: Tor: unspecified
Priority: MediumHigh

I'm in favor here. Does anybody want to make the caching algorithm concrete and write a short proposal for it?

comment:6 Changed 11 months ago by nickm

Keywords: backport? added
Note: See TracTickets for help on using tickets.