mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
a few more thoughts on mirroring dist/ on bridges
svn:r12667
This commit is contained in:
parent
0000c7e6e9
commit
4a03959b10
@ -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
|
||||
@ -109,3 +111,6 @@ Status: Needs-Research
|
||||
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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user