[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:  nickm             
        Type:  defect      |      Status:  needs_review      
    Priority:  major       |   Milestone:  Tor: 0.2.2.x-final
   Component:  Tor Client  |     Version:  0.2.1.19          
  Resolution:  None        |    Keywords:                    
      Parent:              |      Points:                    
Actualpoints:              |  
---------------------------+------------------------------------------------

Comment(by nickm):

 So, there are 8 XXX022-1090 issues as of the head of my XXX1090-branch
 today:

  * In circuitbuild.c, choose_good_exit_server_general(): Currently, people
 who set "ExitNodes" do not get restrictions based on router_is_unreliable.
 This creates a partitioning opportunity.
  * In circuitbuild.c, warn_if_last_router_excluded(): The "using anyway"
 warning fires too often, confuses people, and generally freaks everybody
 out.
  * In circuitbuild.c, choose_random_entry(): If we have a chosen exit that
 is in the same family with all our bridges, we currently ignore the family
 rules.  Instead we should probably pick a new exit if we can, or give up
 and try a new circuit, or something.
  * In circuitbuild.c, launch_direct_descriptor_fetch(), and probably
 elsewhere, it's not consistent what we do if we ExcludeNodes a node and
 then list it as a bridge.  My intuition is to not use that bridge: it
 seems to be what we have said we'd do in the case of conflicts between
 EntryNodes and ExcludeNodes.
  * In connection_edge.c, connection_ap_handshake_rewrite_and_attach(), we
 need to deal with foo.exit requests when foo is excluded or excluded as an
 exit.
  * In connection_edge.c, connection_ap_can_use_exit(), we need to untangle
 some logic, figure out what the function's used for, and generally mash it
 into shape.
  * In router.c, in consider_testing_reachability(), we need to decide what
 happens to reachability tests if we have excluded ourselves and set
 StrictNodes.  I lean to saying "Hey, you excluded yourself. What the hey?"
 and never learning that you are reachable.  If we've excluded ourselves
 and *not* set StrictNodes, then I say this should work.

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