a few more thoughts on mirroring dist/ on bridges

svn:r12667
This commit is contained in:
Roger Dingledine 2007-12-04 18:34:30 +00:00
parent 0000c7e6e9
commit 4a03959b10

View File

@ -1,5 +1,5 @@
Filename: 127-dirport-mirrors-downloads.txt 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$ Version: $Revision$
Last-Modified: $Date$ Last-Modified: $Date$
Author: Roger Dingledine Author: Roger Dingledine
@ -14,7 +14,7 @@ Status: Needs-Research
We have a big pile of mirrors (google for "Tor mirrors"), but few of 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 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 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. 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 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 Check out the connection_ap_make_link() function, as called from
directory.c. Tor clients use this to create a "fake" socks connection directory.c. Tor clients use this to create a "fake" socks connection
back to themselves, and then they attach a directory request to it, 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. 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 We could relay the connections directly to the download site -- but
this produces recognizable outgoing traffic on the bridge or cache's this produces recognizable outgoing traffic on the bridge or cache's
network, which will probably surprise our nice volunteers. (Is this network, which will probably surprise our nice volunteers. (Is this
a good enough reason to discard the direct connection idea?) a good enough reason to discard the direct connection idea?)
But we still have a choice: should we do a one-hop begindir-style Even if we don't do direct connections, should we do a one-hop
connection to the mirror site (make a one-hop circuit to it, then send a begindir-style connection to the mirror site (make a one-hop circuit
'begindir' cell down the circuit), or should we do a normal three-hop to it, then send a 'begindir' cell down the circuit), or should we do
anonymized connection? a normal three-hop anonymized connection?
If these mirrors are mainly bridges, doing a one-hop connection creates If these mirrors are mainly bridges, doing either a direct or a one-hop
another way to enumerate bridges. That would argue for three-hop. On connection creates another way to enumerate bridges. That would argue
the other hand, downloading a 10+ megabyte installer through a normal for three-hop. On the other hand, downloading a 10+ megabyte installer
Tor circuit can't be fun. But if you're already getting throttled a through a normal Tor circuit can't be fun. But if you're already getting
lot because you're in the "relayed traffic" bucket, you're going to throttled a lot because you're in the "relayed traffic" bucket, you're
have to accept a slow transfer anyway. So three-hop it is. going to have to accept a slow transfer anyway. So three-hop it is.
Speaking of which, we would want to label this connection Speaking of which, we would want to label this connection
as "relay" traffic for the purposes of rate limiting; see as "relay" traffic for the purposes of rate limiting; see
connection_counts_as_relayed_traffic() and or_conn->client_used. This 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 4. Scanning resistance
@ -69,10 +70,11 @@ Status: Needs-Research
it hard to scan large swaths of the Internet to look for responses it hard to scan large swaths of the Internet to look for responses
that indicate a bridge. that indicate a bridge.
In general this is a really hard problem, so it's not critical that In general this is a really hard problem, so we shouldn't demand to
we solve it here. But we can note that some bridges should open their solve it here. But we can note that some bridges should open their
DirPort (and offer this functionality), and others shouldn't. Then some DirPort (and offer this functionality), and others shouldn't. Then
bridges provide a download mirror while others are scanning-resistant. some bridges provide a download mirror while others can remain
scanning-resistant.
5. Integrity checking 5. Integrity checking
@ -87,7 +89,7 @@ Status: Needs-Research
Answer #1: Users need to do pgp signature checking. Not a very good 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 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 Answer #2: The mirrors could exit from a specific Tor relay, using the
'.exit' notation. This would make connections a bit more brittle, but '.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, 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 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 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 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 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 dirport, or renegotiate and become a Tor connection, depending on how
the client behaves. the client behaves.
I suggest we go with Answers 2 and 3 for now, and keep 4 in mind for
down the road.