Re: [tor-bugs] #17297 [Tor Check]: TorCheck fails on new exit egress IP not in exit DB, confusing to users

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17297: TorCheck fails on new exit egress IP not in exit DB, confusing to users
-----------------------+-------------------------
 Reporter:  starlight  |          Owner:  arlolra
     Type:  defect     |         Status:  new
 Priority:  High       |      Milestone:
Component:  Tor Check  |        Version:
 Severity:  Normal     |     Resolution:
 Keywords:             |  Actual Points:
Parent ID:             |         Points:
  Sponsor:             |
-----------------------+-------------------------

Comment (by starlight):

 Looking further it becomes apparent that TorDNSEL and
 all other critical exit "scanners" are not actually
 "scanning" anything.  They rely on published exit
 policies to determine exit IP addresses.

 This is a fundamental design defect as the approach
 is not reliable and never will be reliable.  Is
 simple for an exit operator to override the exit
 policy in `torrc`, and if that capability were
 removed nothing prevents hacking of the code
 to the same effect.

 The correct approach is to actually scan the
 network periodically while making note of the
 SOCKS connection source IP and passing this
 information to a scan receiver daemon/thread
 via a cryptographically signed message in order
 to detect and properly document NAT translations.
 The implementation must take into account that
 a single exit relay may have several exit IPs
 that will be employed over time.

 The negative consequences of unreliable exit
 IP documentation includes especially problems
 of perception and reputation for exit node
 operators, who do not enjoy investing substantial
 time and money in a relay only to encounter
 trouble with their ISP due to the common use of
 unreliable alternative lists such as SecToor
 /24 which impose collateral damage to
 uninvolved, innocent third parties.

 Any collaterally damaged third-parties
 encountering network blocks caused by
 a neighboring Tor exit are correct to
 feel abused the the situation.

 It seems that several alternative exit scanners
 exist, including

 https://n0where.net/tor-exit-relay-scanner-exitmap/

 and it is reasonable to assert that one of these
 should be deployed in place of the current unacceptably
 broken system.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17297#comment:8>
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