commit f94f6f3bb6c8a8f407f4b187d6cfb536b13e46ce Author: Andrew Lewman <andrew@torproject.org> Date: Thu Aug 16 22:11:55 2012 -0400 add the tor exitlist design doc into the repo. --- doc/torel-design.txt | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 181 insertions(+), 0 deletions(-) diff --git a/doc/torel-design.txt b/doc/torel-design.txt new file mode 100644 index 0000000..610cbe2 --- /dev/null +++ b/doc/torel-design.txt @@ -0,0 +1,181 @@ +Design For A Tor DNS-based Exit List + +Status: + + This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes. + See http://exitlist.torproject.org/ for an implementation. + +Why? + + It's useful for third parties to be able to tell when a given connection + is coming from a Tor exit node. Potential applications range from + "anonymous user" cloaks on IRC networks like oftc, to networks like + Freenode that apply special authentication rules to users from these + IPs, to systems like Wikipedia that may want to make a priority of + _unblocking_ shared IPs more liberally than non-shared IPs, since shared + IPs presumably have non-abusive users as well as abusive ones. + + Since Tor provides exit policies, not every Tor server will connect to + every address:port combination on the Internet. Unless you're trying to + penalize hosts for supporting anonymity, it makes more sense to answer + the fine-grained question "which Tor servers will connect to _me_?" than + the coarse-grained question "which Tor servers exist?" The fine-grained + approach also helps Tor server ops who share an IP with their Tor + server: if they want to access a site that blocks Tor users, they + can exclude that site from their exit policy, and the site can learn + that they won't send it anonymous connections. + + Tor already ships with a tool (the "contrib/exitlist" script) to + identify which Tor nodes might open anonymous connections to any given + exit address. But this is a bit tricky to set up, so only sites like + Freenode and OFTC that are dedicated to privacy use it. + Conversely, providers of some DNSEL implementations are providing + coarse-grained lists of Tor hosts -- sometimes even listing servers that + permit no exit connections at all. This is rather a problem, since + support for DNSEL is pretty ubiquitous. + + +How? + + Keep a running Tor instance, and parse the cached-routers and + cached-routers.new files as new routers arrive. To tell whether a given + server allows connections to a certain address:port combo, look at the + definitions in dir-spec.txt or follow the logic of the current exitlist + script. If bug 405 is still open when you work on this + (https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll + probably want to extend it to look at only the newest descriptor for + each server, so you don't use obsolete exit policy data. + + FetchUselessDescriptors would probably be a good torrc option to enable. + + If you're also running a directory cache, you get extra-fresh + information. + + +The DNS interface + + Standard DNSEL, if I understand right, looks like this: There's some + authoritative name server for foo.example.com. You want to know if + 1.2.3.4 is in the list, so you query for an A record for + 4.3.2.1.foo.example.com. If the record exists and has the value + 127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list. If you get an NXDOMAIN + error, 1.2.3.4 is not in the list. If you ask for a domain name outside + of the foo.example.com zone, you get a Server Failure error[RFC 1035]. + + Assume that the DNSEL answers queries authoritatively for some zone, + torhosts.example.com. Below are some queries that could be supported, + though some of them are possibly a bad idea. + + + Query type 1: "General IP:Port" + + Format: + {IP1}.{port}.{IP2}.ip-port.torhosts.example.com + + Rule: + Iff {IP1} is a Tor server that permits connections to {port} on + {IP2}, then there should be an A record with the value 127.0.0.2. + + Example: + "1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the + value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1 + that allows connections to port 80 on 1.2.3.4. + + Example use: + I'm running an IRC server at w.x.y.z:9999, and I want to tell + whether an incoming connection is from a Tor server. I set + up my IRC server to give a special mask to any user coming from + an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com. + + Later, when I get a connection from a.b.c.d, my ircd looks up + "d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see + if it's a Tor server that allows connections to my ircd. + + + Query type 2: "IP-port group" + + Format: + {IP}.{listname}.list.torhosts.example.com + + Rule: + Iff this Tor server is configured with an IP:Port list named + {listname}, and {IP} is a Tor server that permits connections to + any member of {listname}, then there exists an A record. + + Example: + Suppose torhosts.example.com has a list of IP:Port called "foo". + There is an A record for 4.3.2.1.foo.list.torhosts.example.com + if and only if 1.2.3.4 is a Tor server that permits connections + to one of the addresses in list "foo". + + Example use: + Suppose torhosts.example.com has a list of hosts in "examplenet", + a popular IRC network. Rather than having them each set up to + query the appropriate "ip-port" list, they could instead all be + set to query a central examplenet.list.torhosts.example.com. + + Problems: + We'd be better off if each individual server queried about hosts + that allowed connections to itself. That way, if I wanted to + allow anonymous connections to foonet, but I wanted to be able to + connect to foonet from my own IP without being marked, I could add + just a few foonet addresses to my exit policy. + + + Query type 3: "My IP, with port" + + Format: + {IP}.{port}.me.torhosts.example.com + + Rule: + An A record exists iff there is a tor server at {IP} that permits + connections to {port} on the host that requested the lookup. + + Example: + "4.3.2.1.80.me.torhosts.example.com" should have an A record if + and only if there is a Tor server at 1.2.3.4 that allows + connections to port 80 of the querying host. + + Example use: + Somebody wants to set up a quick-and-dirty Tor detector for a + single webserver: just point them at 80.me.torhosts.example.com. + + Problem: + This would be easiest to use, but DNS gets in the way. If you + create DNS records that give different results depending on who is + asking, you mess up caching. There could be a fix here, but might + not. + + + RECOMMENDATION: Just build ip-port for now, and see what demand is + like. There's no point in building mechanisms nobody wants. + +Web interface: + + Should provide the same data as the dns interface. + +Other issues: + + After a Tor server op turns off their server, it stops publishing server + descriptors. We should consider that server's IP address to still + represent a Tor node until 48 hours after its last descriptor was + published. + + 30-60 minutes is not an unreasonable TTL. + + There could be some demand for address masks and port lists. Address + masks wider than /8 make me nervous here, as do port ranges. + + We need an answer for what to do about hosts which exit from different + IPs than their advertised IP. One approach would be for the DNSEL + to launch periodic requests to itself through all exit servers whose + policies allow it -- and then see where the requests actually come from. + +References: + + [DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for + E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November + 2005. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987.