Explorar o código

more work on the dirport-mirrors-downloads proposal. still not
really solved well yet.


svn:r12690

Roger Dingledine %!s(int64=17) %!d(string=hai) anos
pai
achega
8b2585854a
Modificáronse 1 ficheiros con 35 adicións e 15 borrados
  1. 35 15
      doc/spec/proposals/127-dirport-mirrors-downloads.txt

+ 35 - 15
doc/spec/proposals/127-dirport-mirrors-downloads.txt

@@ -31,15 +31,7 @@ Status: Draft
 
 
     GET /tor/website/$1
     GET /tor/website/$1
 
 
-2. Linked connections
+2. Direct connections, one-hop circuits, or three-hop circuits?
-
-  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 can piggyback on
-  this feature.
-
-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
@@ -64,7 +56,7 @@ Status: Draft
   will be a bit tricky though, because these connections will use the
   will be a bit tricky though, because these connections will use the
   bridge's guards.
   bridge's guards.
 
 
-4. Scanning resistance
+3. Scanning resistance
 
 
   One other goal we'd like to achieve, or at least not hinder, is making
   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
   it hard to scan large swaths of the Internet to look for responses
@@ -76,7 +68,7 @@ Status: Draft
   some bridges provide a download mirror while others can remain
   some bridges provide a download mirror while others can remain
   scanning-resistant.
   scanning-resistant.
 
 
-5. Integrity checking
+4. Integrity checking
 
 
   If we serve this stuff in plaintext from the bridge, anybody in between
   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.
   the user and the bridge can intercept and modify it. The bridge can too.
@@ -97,11 +89,14 @@ Status: Draft
   among several, and the list could be dynamic -- for example, all the
   among several, and the list could be dynamic -- for example, all the
   relays with an Authority flag that allow exits to the Tor website.
   relays with an Authority flag that allow exits to the Tor website.
 
 
-  Answer #3: We could suggest that users only use trusted bridges for
+  Answer #3: The mirrors should connect to the main distribution site
+  via SSL. That way the exit relay can't influence anything.
+
+  Answer #4: We could suggest that users only use trusted bridges for
   fetching a copy of Tor. Hopefully they heard about the bridge from a
   fetching a copy of Tor. Hopefully they heard about the bridge from a
   trusted source rather than from the adversary.
   trusted source rather than from the adversary.
 
 
-  Answer #4: What if the adversary is trawling for Tor downloads by
+  Answer #5: What if the adversary is trawling for Tor downloads by
   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
@@ -111,7 +106,32 @@ Status: Draft
   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
+5. Linked connections: at what level should we proxy?
-  down the road.
+
+  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 can piggyback on
+  this feature.
 
 
+  We need to decide if we're going to be passing the bytes back and
+  forth between the web browser and the main distribution site, or if
+  we're going to be actually acting like a proxy (parsing out the file
+  they want, fetching that file, and serving it back).
+
+  Advantages of proxying without looking inside:
+    - We don't need to build any sort of http support (including
+      continues, partial fetches, etc etc).
+  Disadvantages:
+    - If the browser thinks it's speaking http, are there easy ways
+      to pass the bytes to an https server and have everything work
+      correctly? At the least, it would seem that the browser would
+      complain about the cert. More generally, ssl wants to be negotiated
+      before the URL and headers are sent, yet we need to read the URL
+      and headers to know that this is a mirror request; so we have an
+      ordering problem here.
+    - Makes it harder to do caching later on, if we don't look at what
+      we're relaying. (It might be useful down the road to cache the
+      answers to popular requests, so we don't have to keep getting
+      them again.)