mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 22:03:31 +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
|
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.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user