|
|
@@ -1,181 +0,0 @@
|
|
|
-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.
|
Nick Mathewson