doc/spec/proposals/127-dirport-mirrors-downloads.txt

   1 Filename: 127-dirport-mirrors-downloads.txt
   2 Title: Relaying dirport requests to Tor download site / website
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Roger Dingledine
   6 Created: 2007-12-02
   7 Status: Draft
   8
   9 1. Overview
  10
  11   Some countries and networks block connections to the Tor website. As
  12   time goes by, this will remain a problem and it may even become worse.
  13
  14   We have a big pile of mirrors (google for "Tor mirrors"), but few of
  15   our users think to try a search like that. Also, many of these mirrors
  16   might be automatically blocked since their pages contain words that
  17   might cause them to get banned. And lastly, we can imagine a future
  18   where the blockers are aware of the mirror list too.
  19
  20   Here we describe a new set of URLs for Tor's DirPort that will relay
  21   connections from users to the official Tor download site. Rather than
  22   trying to cache a bunch of new Tor packages (which is a hassle in terms
  23   of keeping them up to date, and a hassle in terms of drive space used),
  24   we instead just proxy the requests directly to Tor's /dist page.
  25
  26   Specifically, we should support
  27
  28     GET /tor/dist/$1
  29
  30   and
  31
  32     GET /tor/website/$1
  33
  34 2. Direct connections, one-hop circuits, or three-hop circuits?
  35
  36   We could relay the connections directly to the download site -- but
  37   this produces recognizable outgoing traffic on the bridge or cache's
  38   network, which will probably surprise our nice volunteers. (Is this
  39   a good enough reason to discard the direct connection idea?)
  40
  41   Even if we don't do direct connections, should we do a one-hop
  42   begindir-style connection to the mirror site (make a one-hop circuit
  43   to it, then send a 'begindir' cell down the circuit), or should we do
  44   a normal three-hop anonymized connection?
  45
  46   If these mirrors are mainly bridges, doing either a direct or a one-hop
  47   connection creates another way to enumerate bridges. That would argue
  48   for three-hop. On the other hand, downloading a 10+ megabyte installer
  49   through a normal Tor circuit can't be fun. But if you're already getting
  50   throttled a lot because you're in the "relayed traffic" bucket, you're
  51   going to have to accept a slow transfer anyway. So three-hop it is.
  52
  53   Speaking of which, we would want to label this connection
  54   as "relay" traffic for the purposes of rate limiting; see
  55   connection_counts_as_relayed_traffic() and or_conn->client_used. This
  56   will be a bit tricky though, because these connections will use the
  57   bridge's guards.
  58
  59 3. Scanning resistance
  60
  61   One other goal we'd like to achieve, or at least not hinder, is making
  62   it hard to scan large swaths of the Internet to look for responses
  63   that indicate a bridge.
  64
  65   In general this is a really hard problem, so we shouldn't demand to
  66   solve it here. But we can note that some bridges should open their
  67   DirPort (and offer this functionality), and others shouldn't. Then
  68   some bridges provide a download mirror while others can remain
  69   scanning-resistant.
  70
  71 4. Integrity checking
  72
  73   If we serve this stuff in plaintext from the bridge, anybody in between
  74   the user and the bridge can intercept and modify it. The bridge can too.
  75
  76   If we do an anonymized three-hop connection, the exit node can also
  77   intercept and modify the exe it sends back.
  78
  79   Are we setting ourselves up for rogue exit relays, or rogue bridges,
  80   that trojan our users?
  81
  82   Answer #1: Users need to do pgp signature checking. Not a very good
  83   answer, a) because it's complex, and b) because they don't know the
  84   right signing keys in the first place.
  85
  86   Answer #2: The mirrors could exit from a specific Tor relay, using the
  87   '.exit' notation. This would make connections a bit more brittle, but
  88   would resolve the rogue exit relay issue. We could even round-robin
  89   among several, and the list could be dynamic -- for example, all the
  90   relays with an Authority flag that allow exits to the Tor website.
  91
  92   Answer #3: The mirrors should connect to the main distribution site
  93   via SSL. That way the exit relay can't influence anything.
  94
  95   Answer #4: We could suggest that users only use trusted bridges for
  96   fetching a copy of Tor. Hopefully they heard about the bridge from a
  97   trusted source rather than from the adversary.
  98
  99   Answer #5: What if the adversary is trawling for Tor downloads by
 100   network signature -- either by looking for known bytes in the binary,
 101   or by looking for "GET /tor/dist/"? It would be nice to encrypt the
 102   connection from the bridge user to the bridge. And we can! The bridge
 103   already supports TLS. Rather than initiating a TLS renegotiation after
 104   connecting to the ORPort, the user should actually request a URL. Then
 105   the ORPort can either pass the connection off as a linked conn to the
 106   dirport, or renegotiate and become a Tor connection, depending on how
 107   the client behaves.
 108
 109 5. Linked connections: at what level should we proxy?
 110
 111   Check out the connection_ap_make_link() function, as called from
 112   directory.c. Tor clients use this to create a "fake" socks connection
 113   back to themselves, and then they attach a directory request to it,
 114   so they can launch directory fetches via Tor. We can piggyback on
 115   this feature.
 116
 117   We need to decide if we're going to be passing the bytes back and
 118   forth between the web browser and the main distribution site, or if
 119   we're going to be actually acting like a proxy (parsing out the file
 120   they want, fetching that file, and serving it back).
 121
 122   Advantages of proxying without looking inside:
 123     - We don't need to build any sort of http support (including
 124       continues, partial fetches, etc etc).
 125   Disadvantages:
 126     - If the browser thinks it's speaking http, are there easy ways
 127       to pass the bytes to an https server and have everything work
 128       correctly? At the least, it would seem that the browser would
 129       complain about the cert. More generally, ssl wants to be negotiated
 130       before the URL and headers are sent, yet we need to read the URL
 131       and headers to know that this is a mirror request; so we have an
 132       ordering problem here.
 133     - Makes it harder to do caching later on, if we don't look at what
 134       we're relaying. (It might be useful down the road to cache the
 135       answers to popular requests, so we don't have to keep getting
 136       them again.)
 137
 138 6. Outstanding problems
 139
 140   1) HTTP proxies already exist.  Why waste our time cloning one
 141   badly? When we clone existing stuff, we usually regret it.
 142
 143   2) It's overbroad.  We only seem to need a secure get-a-tor feature,
 144   and instead we're contemplating building a locked-down HTTP proxy.
 145
 146   3) It's going to add a fair bit of complexity to our code.  We do
 147   not currently implement HTTPS.  We'd need to refactor lots of the
 148   low-level connection stuff so that "SSL" and "Cell-based" were no
 149   longer synonymous.
 150
 151   4) It's still unclear how effective this proposal would be in
 152   practice. You need to know that this feature exists, which means
 153   somebody needs to tell you about a bridge (mirror) address and tell
 154   you how to use it. And if they're doing that, they could (e.g.) tell
 155   you about a gmail autoresponder address just as easily, and then you'd
 156   get better authentication of the Tor program to boot.
 157