[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 am new here so am still trying to form a mental model to reason about
this system. Here's what I have so far, let me know if it's correct and/or
useful.
For preciseness, I am going to state, explicitly, the IN-interface and
OUT-interface of each component. (This will also help with any general
plugin-composition framework later on.) For example, this is what a
typical normal Tor channel, without transport plugins, looks like:
:SOCKS(U)|tor-c|A=Tor(U): ->
:A=Tor(U)|tor-s|B=Tor(U): ->
:B=Tor(U)|tor-s|C=Tor(U): ->
:C=Tor(U)|tor-s|U:
where A=X means a channel A using protocol X, and X(U) means something
that wraps U. A could be e.g. a inet socket, or a file descriptor, or some
combination of these. To chain stuff correctly, we must ensure the OUT-
interface of one component matches the IN-interface of the next component.
(Technically we should write Z=SOCKS(U), D=U for the first,last
components, but since we're not using Z,D anywhere I'll just leave them
out.)
With a general transport plugin, the diagram from the client to the server
is:
:SOCKS(U)|tor-c|A=SOCKS(U): ->
:A=SOCKS(U)|plugin-c|X(U): ->
:X(U)|plugin-s|P=SOCKS(U),D=control(X): ->
:P=SOCKS(U),D=control(X)|tor-s|Tor(U):
For obfsproxy:
:SOCKS(U)|tor-c|A=SOCKS(U): ->
:A=SOCKS(U)|obfs-c|B=obfs(U): ->
:B=obfs(U)|obfs-s|P=SOCKS(U),Q=control(B): ->
:P=SOCKS(U),Q=control(B)|tor-s|Tor(U):
For flashproxy:
:SOCKS(U)|tor-c|A=SOCKS(U): ->
:A=SOCKS(U)|flash-c|B=flash(U): ->
:B=flash(U)|flash-s|P=SOCKS(U),Q=control(B): ->
:P=SOCKS(U),Q=control(B)|tor-s|Tor(U):
For obfs-flash-proxy, then, an incomplete "first attempt" using naiving
layering:
:SOCKS(U)|tor-c|A=SOCKS(U): ->
:A=SOCKS(U)|obfs-c|B=obfs(U): ->
:B=OU|super|C=SOCKS(OU): -> # where OU == obfs(U)
:C=SOCKS(OU)|flash-c|D=flash(OU): ->
:D=flash(OU)|flash-s|P=SOCKS(OU),Q=control(D): ->
??
:R=obfs(U)|obfs-s|S=Tor(U),T=control(R): ->
:S=SOCKS(U),T=control(R)|tor-s|Tor(U):
So we have two problems here:
- how to implement ?? - we need a component that reads input from an OUT-
interface of {SOCKS(X),control(D)}, and writes output to an IN-interface
of {X}.
- as written, using this naive layering architecture, we have no way of
connecting the control(D) channel to something. what we really want to do
is turn the T=control(R) into a T=control(D), since the former is an
implementation detail and the latter is the user-originated data that we
need to actually control.
I'll need some more time working out the precise details, but a quick read
gives me the impression that the super_1/super_2 solution proposed above
solves these two problems by re-architecting the OU that passes through
the |flash-s| component into something like OU+D.
Does this make sense, am I correct, and/or did I go overboard with the
notation? :p
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:10>
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