more work on the dirport-mirrors-downloads proposal. still not

really solved well yet.


svn:r12690
This commit is contained in:
Roger Dingledine 2007-12-06 10:54:57 +00:00
parent 94f7f4be6c
commit 8b2585854a

View File

@ -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.)