[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: needs_review
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: SponsorF20131101 flashproxy | Parent:
Points: | Actualpoints:
-----------------------------------------+----------------------------------
Changes (by dcf):
* status: new => needs_review
Comment:
I wrote a simple implementation of obfs3-in-flashproxy. It's just two
shell scripts tying the various programs together. It is even simpler than
[comment:8 option (d)] above--it doesn't handle ExtORPort. But it works
and boostraps--I was using IRC through it today.
{{{
git clone https://www.bamsoftware.com/git/obfs-flash.git
}}}
The scripts are less than 100 lines together, which I hope shows that at
least the basic mechanics of chaining transports aren't that difficult. I
call this implementation "Mk. I," with the idea that Mk. II will be (d)
and Mk. III will be one that correctly handles the ordering of streams
that connect back to the super-proxy.
The server component `obfs-flash-server` is running at
tor1.bamsoftware.com:9500 (173.255.221.44:9500). To run the client part,
use the included `torrc`:
{{{
tor -f torrc
}}}
Wait a few seconds, then open a non-Tor browser running a local flash
proxy:
http://crypto.stanford.edu/flashproxy/embed.html?debug&client=127.0.0.1:9000&relay=173.255.221.44:9500
Remember to wait 60 seconds after 50% bootstrapping. You don't need to do
any port forwarding.
One thing we didn't think about was the flash proxy facilitator. The
reason you have to run your own flash proxy in the instructions above is
that the facilitator doesn't know that it needs to give a obfs3-in-
websocket relay to proxies that are serving certain clients. Obviously
connecting to the plain websocket relay that the facilitator uses now,
won't work. We need to think of a way to allow a client to say that it
wants to connect to a different kind of relay. Like client registration
messages, which currently only contain the client IP and port, could also
contain the nested protocols the client wants to use. The facilitator
would check to see if it knows of any relays having that nesting, and
reply to proxies with an appropriate relay. I have some previous thinking
along these lines in comment:2:ticket:5578, comment:5:ticket:7944.
The next easiest step, I think, is to do a Python reimplementation of the
client side. It will do proper parsing (and error reporting) of PT stdout
output, and remove the need for an external socat program.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:17>
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