From 8ce8a41e457385ede04c9f07439ac1842cea7944 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Thu, 6 Dec 2007 10:54:57 +0000 Subject: more work on the dirport-mirrors-downloads proposal. still not really solved well yet. svn:r12690 --- proposals/127-dirport-mirrors-downloads.txt | 50 ++++++++++++++++++++--------- 1 file changed, 35 insertions(+), 15 deletions(-) (limited to 'proposals/127-dirport-mirrors-downloads.txt') diff --git a/proposals/127-dirport-mirrors-downloads.txt b/proposals/127-dirport-mirrors-downloads.txt index 106bbb4..9a07dcd 100644 --- a/proposals/127-dirport-mirrors-downloads.txt +++ b/proposals/127-dirport-mirrors-downloads.txt @@ -31,15 +31,7 @@ Status: Draft 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 @@ -64,7 +56,7 @@ Status: Draft 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 @@ Status: Draft 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 @@ Status: Draft 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 @@ Status: Draft 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.) -- cgit v1.2.3-54-g00ecf