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

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Jan 4 10:50:27 UTC 2017


#14917: Client's choice of rend point can leak info about hidden service's guard
relay
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  dgoulet
     Type:  defect                               |         Status:  closed
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.2.7.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, 027-triaged-1-in, SponsorU,  |  implemented
  TorCoreTeam201509, PostFreeze027               |  Actual Points:
Parent ID:                                       |         Points:  medium
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorR
-------------------------------------------------+-------------------------
Changes (by Jaym):

 * severity:   => Normal


Comment:

 Hello !

 I discovered this thread while configuring an onion service with the
 EntryNodes option set. I believe (after checking the tor-0.2.9.8 source
 code) that a similar problem arises when the EntryNodes option is set AND
 the operator configures entry nodes that are part of the same family or
 the same /16. (let's say that the operator configures the service with its
 own guard nodes running in the same cloud provider, thinking this move is
 wise). Then this happens:

 - When someone use a RDV point of the same family or the same /16 than the
 onion's guards, then as you said: "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".

 Is there a reason why we do not check family, /16 and user
 misconfiguration ? "EntryNodes fingerprint1, fingerprint1" works just fine
 for example. What do you think ?

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


More information about the tor-bugs mailing list