[tor-bugs] #14917 [Tor]: Client's choice of rend point can leak info about hidden service's guard relay

[Tor Bug Tracker & Wiki]

#14917: Client's choice of rend point can leak info about hidden service's guard
relay
------------------------------+------------------------------------
 Reporter:  arma              |          Owner:
     Type:  defect            |         Status:  new
 Priority:  normal            |      Milestone:  Tor: 0.2.7.x-final
Component:  Tor               |        Version:
 Keywords:  SponsorR, tor-hs  |  Actual Points:
Parent ID:                    |         Points:
------------------------------+------------------------------------
 Imagine the scenario where the attacking client picks a rendezvous point
 that happens to be the hidden service's primary (first) entry guard. Then
 * The hidden service will look through its preemptively built circuits to
 see if it can extend any of them. circuit_find_to_cannibalize() will
 decide that none of the existing circuits are suitable, because they would
 cause a duplicate hop.
 * So the hidden service decides to make a new circuit. In
 populate_live_entry_guards() it compares node to chosen_exit and then
 exit_family, and skips it if there's overlap.

 So the result is that even when NumEntryGuards is 1, the hidden service
 will end up using its *second* entry guard for this circuit. Surprising.
 This isn't terrible, since I don't see any way to induce it to contact a
 third entry guard, but still, two is more than one, especially when you
 thought you were getting only one. (Imagine an attack where the adversary
 has you rendezvous with every relay that has the Guard flag -- now you're
 guaranteed to step over to your second guard at least once.)

 Where it gets messy is if the user explicitly set EntryNodes, like some
 hidden service operators think is wise, so they can use an entry node they
 trust. In that case entry_list_is_constrained() is true, so
 populate_live_entry_guards() will happily return an empty list if your one
 choice is inappropriate, resulting in choose_random_entry_impl() returning
 NULL. The external behavior is that if you send the hidden service the
 right rendezvous point, it never connects. That's kind of bad, especially
 since some people argue setting an explicit EntryNode is a wise move.

 Now, learning about the hidden service's choice of primary guard isn't the
 end of the world, because there are other reasonably straightforward ways
 to enumerate the entry guard of a hidden service currently, e.g. the
 predecessor attack (run a middle relay, rendezvous with the hidden service
 many times, and see which prior hop shows up in the circuit the most
 times). But we'd like to fix those, e.g. by moving to a layered entry
 guard design, and if we do, this issue will remain.

 Reported by 'ghetto' on irc.

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