[tor-bugs] #1090 [Tor Client]: Warning about using an excluded node for exit

[Tor Bug Tracker & Wiki]

#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