torel-design.txt 7.4 KB

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