[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7167 [Pluggable transport]: Combine traffic obfuscation with address diversity of flash proxy
#7167: Combine traffic obfuscation with address diversity of flash proxy
-----------------------------------------+----------------------------------
Reporter: karsten | Owner: asn
Type: project | Status: new
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: SponsorF20131101 flashproxy | Parent:
Points: | Actualpoints:
-----------------------------------------+----------------------------------
Comment(by infinity0):
Summary from IRC today: we decided to try to implement (d) first because
it's the simplest, even though it's only correct when certain assumptions
hold, about how Tor actually uses the metadata/headers from the ORPort
protocol.
Additionally, I have another variant which I was trying to communicate on
IRC earlier, but I'm not sure if I did a good job of it. I don't think
it's much more complex than (d), and is fully correct without relying on
the above assumptions. It mixes ideas from (a) and (c), using different
ports to distinguish between clients, in order to avoid both using a new
custom protocol (as in (b)), or requiring obfsproxy to be modified to
accept ORPort (as in (a)).
To recap, for (c) we need to somehow "tell" obfsproxy to send its output
to different ports. One way to achieve this is to start a new instance of
obfsproxy for each client connection, telling it to listen on a different
port. To avoid having to start a new instance of flashproxy too, we move
the |super_1| component *after* it. So the diagram looks like this:
|flashproxy| -> |super_1| -> |obfsproxy| -> |super_2| -> |Tor|
1. super_1 reads ORPort from flashproxy, stores all headers (COMMANDS
using terminology of spec 196) and associates this info with some random
port P
2. super_1 tells super_2 to listen on port P (can do this in-process)
3. super_1 opens a new instance of obfsproxy, with its ORPort set to P.
4. super_1 sends BODY to obfsproxy
5. obfsproxy processes this and sends ORPort output to super_2, on port P.
6. super_2 reads ORPort from obfsproxy on port P, looks up the headers
associated with P and sends these to Tor
7. super_2 skips the headers from the incoming channel (since they are
from obfsproxy and not flashproxy), then forwards BODYLEN/BODY directly
onto Tor
In summary, super_1 receives extended ORPort protocol, and outputs raw
data; super_2 receives and outputs extended ORPort protocol.
Advantages:
- super_1/super_2 do not need to know what flashproxy/obfsproxy do -
(except, super_1 needs to know how to start up obfsproxy, but any super-
proxy must know this info)
- flashproxy/obfsproxy do not need to be changed
Disadvantages:
- a new obfsproxy process is created for each client connection.
Things not considered:
- ORPort authentication
- TransportControlPort
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs