[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #14917 [Core Tor/Tor]: Client's choice of rend point can leak info about hidden service's guard relay
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs