[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r12640: some notes on tor dist/ and website/ mirrors via dir caches (tor/trunk/doc/spec/proposals)
Author: arma
Date: 2007-12-02 09:41:39 -0500 (Sun, 02 Dec 2007)
New Revision: 12640
Added:
tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt
Modified:
tor/trunk/doc/spec/proposals/000-index.txt
tor/trunk/doc/spec/proposals/126-geoip-reporting.txt
Log:
some notes on tor dist/ and website/ mirrors via dir caches
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-12-02 13:51:16 UTC (rev 12639)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-12-02 14:41:39 UTC (rev 12640)
@@ -48,7 +48,8 @@
123 Naming authorities automatically create bindings [OPEN]
124 Blocking resistant TLS certificate usage [ACCEPTED]
125 Behavior for bridge users, bridge relays, and bridge authorities [OPEN]
-126 Fetching GeoIP databases for clients, relays, and bridges [OPEN]
+126 Getting GeoIP data and publishing usage summaries [NEEDS-RESEARCH]
+127 Relaying dirport requests to Tor download site [NEEDS-RESEARCH]
Proposals by status:
@@ -64,12 +65,13 @@
121 Hidden Service Authentication
123 Naming authorities automatically create bindings
125 Behavior for bridge users, bridge relays, and bridge authorities
- 126 Fetching GeoIP databases for clients, relays, and bridges
ACCEPTED:
105 Version negotiation for the Tor protocol
124 Blocking resistant TLS certificate usage
NEEDS-RESEARCH:
118 Advertising multiple ORPorts at once
+ 126 Getting GeoIP data and publishing usage summaries
+ 127 Relaying dirport requests to Tor download site
META:
000 Index of Tor Proposals
001 The Tor Proposal Process
Modified: tor/trunk/doc/spec/proposals/126-geoip-reporting.txt
===================================================================
--- tor/trunk/doc/spec/proposals/126-geoip-reporting.txt 2007-12-02 13:51:16 UTC (rev 12639)
+++ tor/trunk/doc/spec/proposals/126-geoip-reporting.txt 2007-12-02 14:41:39 UTC (rev 12640)
@@ -4,7 +4,7 @@
Last-Modified: $Date: 2007-10-16 12:59:42 -0400 (Tue, 16 Oct 2007) $
Author: Roger Dingledine
Created: 2007-11-24
-Status: Researching
+Status: Needs-Research
1. Background and motivation
Added: tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt
===================================================================
--- tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt 2007-12-02 14:41:39 UTC (rev 12640)
@@ -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.
+