From 194bbe0b1c352a0beadb30ed701509461f566286 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Tue, 4 Dec 2007 18:34:30 +0000 Subject: a few more thoughts on mirroring dist/ on bridges svn:r12667 --- proposals/127-dirport-mirrors-downloads.txt | 47 ++++++++++++++++------------- 1 file changed, 26 insertions(+), 21 deletions(-) (limited to 'proposals/127-dirport-mirrors-downloads.txt') diff --git a/proposals/127-dirport-mirrors-downloads.txt b/proposals/127-dirport-mirrors-downloads.txt index 24b27e8..18ca007 100644 --- a/proposals/127-dirport-mirrors-downloads.txt +++ b/proposals/127-dirport-mirrors-downloads.txt @@ -1,5 +1,5 @@ Filename: 127-dirport-mirrors-downloads.txt -Title: Relaying dirport requests to Tor download site +Title: Relaying dirport requests to Tor download site / website Version: $Revision$ Last-Modified: $Date$ Author: Roger Dingledine @@ -14,7 +14,7 @@ Status: Needs-Research 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 + might cause them to get banned. 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 @@ -36,32 +36,33 @@ Status: Needs-Research 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 + so they can launch directory fetches via Tor. We can piggyback on this feature. -3. One-hop circuits or three-hop circuits? +3. Direct connections, 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? + Even if we don't do direct connections, 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. + If these mirrors are mainly bridges, doing either a direct or 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. + will be a bit tricky though, because these connections will use the + bridge's guards. 4. Scanning resistance @@ -69,10 +70,11 @@ Status: Needs-Research 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. + In general this is a really hard problem, so we shouldn't demand to + 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 can remain + scanning-resistant. 5. Integrity checking @@ -87,7 +89,7 @@ Status: Needs-Research 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. + right signing keys 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 @@ -103,9 +105,12 @@ Status: Needs-Research 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 + 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. + I suggest we go with Answers 2 and 3 for now, and keep 4 in mind for + down the road. + -- cgit v1.2.3-54-g00ecf