attic/torel-design.txt

   1 Design For A Tor DNS-based Exit List
   2
   3 Status:
   4
   5   This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes.
   6   See http://exitlist.torproject.org/ for an implementation.
   7
   8 Why?
   9
  10   It's useful for third parties to be able to tell when a given connection
  11   is coming from a Tor exit node.  Potential applications range from
  12   "anonymous user" cloaks on IRC networks like oftc, to networks like
  13   Freenode that apply special authentication rules to users from these
  14   IPs, to systems like Wikipedia that may want to make a priority of
  15   _unblocking_ shared IPs more liberally than non-shared IPs, since shared
  16   IPs presumably have non-abusive users as well as abusive ones.
  17
  18   Since Tor provides exit policies, not every Tor server will connect to
  19   every address:port combination on the Internet.  Unless you're trying to
  20   penalize hosts for supporting anonymity, it makes more sense to answer
  21   the fine-grained question "which Tor servers will connect to _me_?" than
  22   the coarse-grained question "which Tor servers exist?"  The fine-grained
  23   approach also helps Tor server ops who share an IP with their Tor
  24   server: if they want to access a site that blocks Tor users, they
  25   can exclude that site from their exit policy, and the site can learn
  26   that they won't send it anonymous connections.
  27
  28   Tor already ships with a tool (the "contrib/exitlist" script) to
  29   identify which Tor nodes might open anonymous connections to any given
  30   exit address.  But this is a bit tricky to set up, so only sites like
  31   Freenode and OFTC that are dedicated to privacy use it.
  32   Conversely, providers of some DNSEL implementations are providing
  33   coarse-grained lists of Tor hosts -- sometimes even listing servers that
  34   permit no exit connections at all.  This is rather a problem, since
  35   support for DNSEL is pretty ubiquitous.
  36
  37
  38 How?
  39
  40   Keep a running Tor instance, and parse the cached-routers and
  41   cached-routers.new files as new routers arrive.  To tell whether a given
  42   server allows connections to a certain address:port combo, look at the
  43   definitions in dir-spec.txt or follow the logic of the current exitlist
  44   script. If bug 405 is still open when you work on this
  45   (https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll
  46   probably want to extend it to look at only the newest descriptor for
  47   each server, so you don't use obsolete exit policy data.
  48
  49   FetchUselessDescriptors would probably be a good torrc option to enable.
  50
  51   If you're also running a directory cache, you get extra-fresh
  52   information.
  53
  54
  55 The DNS interface
  56
  57   Standard DNSEL, if I understand right, looks like this: There's some
  58   authoritative name server for foo.example.com.  You want to know if
  59   1.2.3.4 is in the list, so you query for an A record for
  60   4.3.2.1.foo.example.com.  If the record exists and has the value
  61   127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list.  If you get an NXDOMAIN
  62   error, 1.2.3.4 is not in the list.  If you ask for a domain name outside
  63   of the foo.example.com zone, you get a Server Failure error[RFC 1035].
  64
  65   Assume that the DNSEL answers queries authoritatively for some zone,
  66   torhosts.example.com.  Below are some queries that could be supported,
  67   though some of them are possibly a bad idea.
  68
  69
  70   Query type 1: "General IP:Port"
  71
  72     Format:
  73         {IP1}.{port}.{IP2}.ip-port.torhosts.example.com
  74
  75     Rule:
  76         Iff {IP1} is a Tor server that permits connections to {port} on
  77         {IP2}, then there should be an A record with the value 127.0.0.2.
  78
  79     Example:
  80         "1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the
  81         value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1
  82         that allows connections to port 80 on 1.2.3.4.
  83
  84     Example use:
  85         I'm running an IRC server at w.x.y.z:9999, and I want to tell
  86         whether an incoming connection is from a Tor server.  I set
  87         up my IRC server to give a special mask to any user coming from
  88         an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com.
  89
  90         Later, when I get a connection from a.b.c.d, my ircd looks up
  91         "d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see
  92         if it's a Tor server that allows connections to my ircd.
  93
  94
  95   Query type 2: "IP-port group"
  96
  97     Format:
  98         {IP}.{listname}.list.torhosts.example.com
  99
 100     Rule:
 101         Iff this Tor server is configured with an IP:Port list named
 102         {listname}, and {IP} is a Tor server that permits connections to
 103         any member of {listname}, then there exists an A record.
 104
 105     Example:
 106         Suppose torhosts.example.com has a list of IP:Port called "foo".
 107         There is an A record for 4.3.2.1.foo.list.torhosts.example.com
 108         if and only if 1.2.3.4 is a Tor server that permits connections
 109         to one of the addresses in list "foo".
 110
 111     Example use:
 112         Suppose torhosts.example.com has a list of hosts in "examplenet",
 113         a popular IRC network.  Rather than having them each set up to
 114         query the appropriate "ip-port" list, they could instead all be
 115         set to query a central examplenet.list.torhosts.example.com.
 116
 117     Problems:
 118         We'd be better off if each individual server queried about hosts
 119         that allowed connections to itself.  That way, if I wanted to
 120         allow anonymous connections to foonet, but I wanted to be able to
 121         connect to foonet from my own IP without being marked, I could add
 122         just a few foonet addresses to my exit policy.
 123
 124
 125   Query type 3: "My IP, with port"
 126
 127     Format:
 128         {IP}.{port}.me.torhosts.example.com
 129
 130     Rule:
 131         An A record exists iff there is a tor server at {IP} that permits
 132         connections to {port} on the host that requested the lookup.
 133
 134     Example:
 135         "4.3.2.1.80.me.torhosts.example.com" should have an A record if
 136         and only if there is a Tor server at 1.2.3.4 that allows
 137         connections to port 80 of the querying host.
 138
 139     Example use:
 140         Somebody wants to set up a quick-and-dirty Tor detector for a
 141         single webserver: just point them at 80.me.torhosts.example.com.
 142
 143     Problem:
 144         This would be easiest to use, but DNS gets in the way. If you
 145         create DNS records that give different results depending on who is
 146         asking, you mess up caching.  There could be a fix here, but might
 147         not.
 148
 149
 150   RECOMMENDATION: Just build ip-port for now, and see what demand is
 151   like.  There's no point in building mechanisms nobody wants.
 152
 153 Web interface:
 154
 155   Should provide the same data as the dns interface.
 156
 157 Other issues:
 158
 159   After a Tor server op turns off their server, it stops publishing server
 160   descriptors. We should consider that server's IP address to still
 161   represent a Tor node until 48 hours after its last descriptor was
 162   published.
 163
 164   30-60 minutes is not an unreasonable TTL.
 165
 166   There could be some demand for address masks and port lists. Address
 167   masks wider than /8 make me nervous here, as do port ranges.
 168
 169   We need an answer for what to do about hosts which exit from different
 170   IPs than their advertised IP. One approach would be for the DNSEL
 171   to launch periodic requests to itself through all exit servers whose
 172   policies allow it -- and then see where the requests actually come from.
 173
 174 References:
 175
 176   [DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for
 177   E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November
 178   2005.
 179
 180   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
 181   Specification", RFC 1035, November 1987.