some notes on tor dist/ and website/ mirrors via dir caches

svn:r12640

1 files changed, 111 insertions, 0 deletions

diff --git a/proposals/127-dirport-mirrors-downloads.txt b/proposals/127-dirport-mirrors-downloads.txt
new file mode 100644
index 0000000..08c2111
--- /dev/null
+++ b/proposals/127-dirport-mirrors-downloads.txt
@@ -0,0 +1,111 @@
+Filename: 127-dirport-mirrors-downloads.txt
+Title: Relaying dirport requests to Tor download site
+Version: $Revision: 11988 $
+Last-Modified: $Date: 2007-10-16 12:59:42 -0400 (Tue, 16 Oct 2007) $
+Author: Roger Dingledine
+Created: 2007-12-02
+Status: Needs-Research
+
+1. Overview
+
+  Some countries and networks block connections to the Tor website. As
+  time goes by, this will remain a problem and it may even become worse.
+
+  We have a big pile of mirrors (google for "Tor mirrors"), but few of
+  our users think to try a search like that. Also, many of these mirrors
+  might be automatically blocked since their pages contain words that
+  might cause them to get blocked. And lastly, we can imagine a future
+  where the blockers are aware of the mirror list too.
+
+  Here we describe a new set of URLs for Tor's DirPort that will relay
+  connections from users to the official Tor download site. Rather than
+  trying to cache a bunch of new Tor packages (which is a hassle in terms
+  of keeping them up to date, and a hassle in terms of drive space used),
+  we instead just proxy the requests directly to Tor's /dist page.
+
+  Specifically, we should support
+
+    GET /tor/dist/$1
+
+  and
+
+    GET /tor/website/$1
+
+2. Linked connections
+
+  Check out the connection_ap_make_link() function, as called from
+  directory.c. Tor clients use this to create a "fake" socks connection
+  back to themselves, and then they attach a directory request to it,
+  so they can launch directory fetches via Tor. We could piggyback on
+  this feature.
+
+3. One-hop circuits or three-hop circuits?
+
+  We could relay the connections directly to the download site -- but
+  this produces recognizable outgoing traffic on the bridge or cache's
+  network, which will probably surprise our nice volunteers. (Is this
+  a good enough reason to discard the direct connection idea?)
+
+  But we still have a choice: should we do a one-hop begindir-style
+  connection to the mirror site (make a one-hop circuit to it, then send a
+  'begindir' cell down the circuit), or should we do a normal three-hop
+  anonymized connection?
+
+  If these mirrors are mainly bridges, doing a one-hop connection creates
+  another way to enumerate bridges. That would argue for three-hop. On
+  the other hand, downloading a 10+ megabyte installer through a normal
+  Tor circuit can't be fun. But if you're already getting throttled a
+  lot because you're in the "relayed traffic" bucket, you're going to
+  have to accept a slow transfer anyway. So three-hop it is.
+
+  Speaking of which, we would want to label this connection
+  as "relay" traffic for the purposes of rate limiting; see
+  connection_counts_as_relayed_traffic() and or_conn->client_used. This
+  will be a bit tricky though, because it uses the bridge's guards.
+
+4. Scanning resistance
+
+  One other goal we'd like to achieve, or at least not hinder, is making
+  it hard to scan large swaths of the Internet to look for responses
+  that indicate a bridge.
+
+  In general this is a really hard problem, so it's not critical that
+  we solve it here. But we can note that some bridges should open their
+  DirPort (and offer this functionality), and others shouldn't. Then some
+  bridges provide a download mirror while others are scanning-resistant.
+
+5. Integrity checking
+
+  If we serve this stuff in plaintext from the bridge, anybody in between
+  the user and the bridge can intercept and modify it. The bridge can too.
+
+  If we do an anonymized three-hop connection, the exit node can also
+  intercept and modify the exe it sends back.
+
+  Are we setting ourselves up for rogue exit relays, or rogue bridges,
+  that trojan our users?
+
+  Answer #1: Users need to do pgp signature checking. Not a very good
+  answer, a) because it's complex, and b) because they don't know the
+  right signatures in the first place.
+
+  Answer #2: The mirrors could exit from a specific Tor relay, using the
+  '.exit' notation. This would make connections a bit more brittle, but
+  would resolve the rogue exit relay issue. We could even round-robin
+  among several, and the list could be dynamic -- for example, all the
+  relays with an Authority flag that allow exits to the Tor website.
+
+  Answer #3: We could suggest that users only use trusted bridges for
+  fetching a copy of Tor. Hopefully they heard about the bridge from a
+  trusted source rather than from the adversary.
+
+  Answer #4: What if the adversary is trawling for Tor downloads by
+  network signature -- either by looking for known bytes in the binary,
+  or by looking for "GET /tor/dist/"? It would be nice to encrypt the
+  connection from the bridge user to the bridge. And we can! The bridge
+  already supports TLS.  Rather than initiating a TLS renegotiation after
+  connecting to the ORPort, the user should actually request a URL. Then
+  the ORPort can either pass the connection off as a linked conn to the
+  dirport, or renegotiate and become a Tor connection, depending on how
+  the client behaves.
+