[or-cvs] r12690: more work on the dirport-mirrors-downloads proposal. still n (tor/trunk/doc/spec/proposals)

[arma@xxxxxxxx]

Author: arma
Date: 2007-12-06 05:54:57 -0500 (Thu, 06 Dec 2007)
New Revision: 12690

Modified:
   tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt
Log:
more work on the dirport-mirrors-downloads proposal. still not
really solved well yet.


Modified: tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt
===================================================================
--- tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt	2007-12-06 08:41:52 UTC (rev 12689)
+++ tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt	2007-12-06 10:54:57 UTC (rev 12690)
@@ -31,16 +31,8 @@
 
     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
   this produces recognizable outgoing traffic on the bridge or cache's
   network, which will probably surprise our nice volunteers. (Is this
@@ -64,7 +56,7 @@
   will be a bit tricky though, because these connections will use the
   bridge's guards.
 
-4. Scanning resistance
+3. Scanning resistance
 
   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
@@ -76,7 +68,7 @@
   some bridges provide a download mirror while others can remain
   scanning-resistant.
 
-5. Integrity checking
+4. Integrity checking
 
   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.
@@ -97,11 +89,14 @@
   among several, and the list could be dynamic -- for example, all the
   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
   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,
   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
@@ -111,7 +106,32 @@
   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.
+5. Linked connections: at what level should we proxy?
 
+  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.)
+