mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2025-02-22 22:25:51 +01:00
Code Issues Projects Releases Wiki Activity

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

Browse source 
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
1 changed files with 35 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
doc/spec/proposals/127-dirport-mirrors-downloads.txt
View file

@ -31,15 +31,7 @@ Status: Draft
GET /tor/website/$1 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 We could relay the connections directly to the download site -- but
this produces recognizable outgoing traffic on the bridge or cache's 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 will be a bit tricky though, because these connections will use the
bridge's guards. bridge's guards.
4. Scanning resistance 3. Scanning resistance
One other goal we'd like to achieve, or at least not hinder, is making 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 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 some bridges provide a download mirror while others can remain
scanning-resistant. scanning-resistant.
5. Integrity checking 4. Integrity checking
If we serve this stuff in plaintext from the bridge, anybody in between 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. 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 among several, and the list could be dynamic -- for example, all the
relays with an Authority flag that allow exits to the Tor website. 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 fetching a copy of Tor. Hopefully they heard about the bridge from a
trusted source rather than from the adversary. 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, 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 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 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 dirport, or renegotiate and become a Tor connection, depending on how
the client behaves. the client behaves.
I suggest we go with Answers 2 and 3 for now, and keep 4 in mind for 5. Linked connections: at what level should we proxy?
down the road.
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.)