mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
more work on the dirport-mirrors-downloads proposal. still not
really solved well yet. svn:r12690
This commit is contained in:
parent
94f7f4be6c
commit
8b2585854a
@ -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.)
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user