[tor-bugs] #2667 [Tor]: Exits should block reentry into the tor network

[Tor Bug Tracker & Wiki]

#2667: Exits should block reentry into the tor network
---------------------------+--------------------------------------
     Reporter:  mikeperry  |      Owner:
         Type:  defect     |     Status:  assigned
     Priority:  major      |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor        |    Version:
   Resolution:             |   Keywords:  needs-proposal tor-relay
Actual Points:             |  Parent ID:  #2664
       Points:             |
---------------------------+--------------------------------------

Comment (by s7r):

 For the relays, it's better to make Tor automatically reject exiting *to*
 the IPs in the consensus and not refuse the requests *from* the IP
 addresses in the consensus (most important argument Sebastian's comment
 6). Exit relays are used also in rendezvous circuits, but it shouldn't
 matter since we are talking about the exit policy and not behavior in Tor
 circuits.

 For the bridges, the only way is to refuse requests from the IP addresses
 in the consensus, but just the ones with accept policy in the descriptor.
 A bridge should not care about the Exit flag, because there are relays in
 the consensus which permit exiting to very few ports and do not have the
 Exit flag. These relays have a chance to reach a bridge, if it's listening
 on the right port.

 Either way, for bridges is little bit more complicated. It will make it a
 lot easier for some censors.

 Take for example a network where everyone (maybe behind NAT or not) uses a
 proxy which filters a lot of things and bans a lot of destinations.
 Obviously all IP addresses in Tor network consensus are blacklisted too,
 so these people can only use bridges (with PTs if the censor is also
 fingerprinting traffic). In this case, the censor will not need to hunt
 the bridges in bridge-db (which we try to make so hard), censor can just
 setup a relay on the proxy server IP with lowest possible speed (useless
 for the Tor network) and be sure nobody in their network can connect to
 Tor. Same applies to NAT, where everyone has a single public IP address -
 the proxy example is often seen in practice, especially in companies /
 workplaces even in non-censored countries. Some people won't be able to
 use Tor at work then. This maybe doesn't sound like a terrible issue, but
 a while ago a journalist (at least that's what he said he was) asked me on
 irc to help him setup a private bridge on a vps which he can use at work
 to keep his sources safe and hidden (competition between employees,
 curious senior editors or managers maybe). Tor network was banned at proxy
 end at his workplace. He could use any bridge from bridge-db, wanted a
 dedi one for unknown / unrelated reasons.

 Censored countries also sometimes use a system similar to the one above.
 Bridges will not annoy as much as now these censors. A really insane ISP
 (in an insane country) could even hijack one port from all IP addresses
 they control and setup low speed useless relays on all, so nobody in their
 network can use bridges. This is a little  bit exaggerated and unlikely,
 but not impossible in theory. Already doing DPI and advanced active
 traffic fingerprinting, what would cost them more to try this attack. It
 will cost the directory authorities a lot more.

 This should be implemented only if there are more gains than looses. Is
 Tor over Tor a threat big enough so an unknown number of bridge users can
 be sacrificed?

 If this is merged, it should be the default behavior, no option in torrc
 to turn it off. If it can be turned off or it's not the default behavior
 it means it's not a threat serious enough to risk sacrificing an unknown
 number of bridge users. Implementing it just for relays and not for
 bridges would not make sense either.

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