GET /tor/website/$1
-2. Linked connections
-
- 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?
+2. 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
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
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.
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
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.)
projects / thirdparty / tor.git / commitdiff
