[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):
I should be less hasty claiming "proofs", there are like a million ways of
doing this. My diagram above was actually different from all the solutions
in asn's previous post; here are the corresponding diagrams for each.
Importantly, we always need a shim between flashproxy and obfsproxy,
simply because their input/output interfaces are incompatible (one is
SOCKS, the other isn't) - I've called it super_m.
"a) Make both |flashproxy| and |obfsproxy| Extended ORPort listeners,"
:D=flash(OU)|flash-s|P=SOCKS(OU),Q=control(D): ->
:P=SOCKS(OU),Q|super_m|R=OU,Q'=Q: ->
:R=obfs(U),Q'|modified obfs-s|S=SOCKS(U),T=Q': ->
:S=SOCKS(U),T=control(D)|tor-s|Tor(U):
(Actually, |flash-s| doesn't need to be a listener, in this case.)
"b) Implement yet-another-metadata protocol for this use case."
:D=flash(OU)|super_1|E=flash(ODU): -> # where ODU == obfs(D+U), D+U being
the "custom protocol". Note, this is slightly different from the one I
drew above, but is similar in intent.
:E=flash(ODU)|flash-s|P=SOCKS(ODU),Q=control(E): ->
:P=SOCKS(ODU),Q|super_m|R=ODU: ->
:R=obfs(D+U)|obfs-s|S=SOCKS(D+U),T=control(R): ->
:S=SOCKS(D+U),T|super_2|S'=SOCKS(U),T'=control(D): ->
:S'=SOCKS(U),T'=control(D)|tor-s|Tor(U):
"c) Have |super_2| bind to different local ports to denote different
clients."
This is just a variation of (b) where super_1 can somehow (outside of the
diagram) dynamically change the port that |obfs-s| connects to.
"d) Put client IPs in a queue inside |super| and when |super_2|
connects to the Extended ORPort pop the queue and report that
IP. "
Sounds like incorrect behaviour to me...?
Solution (a) seems the cleanest and re-usable, because of the way the
general transport plugin architecture works. If we are to have arbitrary
composable plugins, the easiest way is to require them to be an Extended
ORPort listener, and passthrough data appropriately. This could be added
to a library to make things easier for developers.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:12>
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