[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1090 [Tor Client]: Warning about using an excluded node for exit
#1090: Warning about using an excluded node for exit
-------------------------+--------------------------------------------------
Reporter: Sebastian | Owner: arma
Type: defect | Status: assigned
Priority: major | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version: 0.2.1.19
Resolution: None | Keywords:
Parent: |
-------------------------+--------------------------------------------------
Comment(by arma):
I talked to nickm about this at the dev mtg. My basic suggested design is
to have EntryNodes be a list of nodes you must use in your first hop of
circuits (except one-hop circuits). If none of your entrynodes are
available, you build no circuits. Exitnodes is a list of nodes you must
use in your last hop of non-internal (as defined in path-spec) circuits.
Similarly, if no exitnodes work, no circuits for you.
ExcludeExitNodes is a list of nodes to never use as the last hop of a non-
internal circuit. Nodes in both exitnodes and excludeexitnodes are
excluded.
ExcludeNodes is the tricky one. There are a variety of cases where a) your
Tor functionality will break if you don't use it, and b) we feel it really
isn't that bad to use it. Generally these come with c) the user will have
no clue that her ExcludeNodes choice is the reason why Tor sucks for them.
Examples include:
1) the introduction point when connecting to a hidden service
2) the rendezvous point when the hidden service answers
3) connecting to the appropriate node to store/fetch a hidden service
descriptor
If the user sets StrictNodes, we'll avoid the nodes in ExcludeNodes even
when it mysteriously breaks Tor's functionality.
Borderline cases that need more thought include:
1) An exit relay that exit enclaves to the IP address the user just asked
for. I guess it can't hurt to exclude it (though imo it also can't hurt to
use it).
2) the directory mirror we randomly chose for fetching directory info.
Probably ExcludeNodes should exclude it but ExcludeExitNodes shouldn't.
I bet we'll find more edge cases to ponder as we implement. Nickm
suggested a code redesign where every time we ask for a router, we specify
why we're asking for it (or at least, what constraints it should obey).
Then we simply don't get back routers that don't obey the constraints we
specify. That approach also makes the code more explicit for each case
about what result we should expect.
People should also look at my commit messages in arma/strictnodes to get a
sense of the various edge cases for EntryNodes and Exitnodes and how I
decided to handle them. (I believe they are all handled appropriately now,
but what do I know.)
See also #2114 and #2411 to reduce the number of Vidalia users who are
confused about why ExcludeExitNodes or ExcludeNodes doesn't do what they
expect.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1090#comment:21>
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