I was thinking that a generalized mechanism for using vpns as obfsproxy transports would help solve for a dns transport... since a dns transport is going to use a tun device. Perhaps obfsproxy/network/launch_transport.py can be changed so that it has a vpn role... where it sets up the tun device and routes an address to that tun device... and then either binds + listens to a particular port (server) or connects to the ip address which is routed over the tun device (client). Obfsproxy in this mode would pass the data straight through like the dummy transport... and the vpn handling the tun device (could either be in the same twisted process or another forked process) takes care of obfuscating the tcp stream by passing the raw ip packets into dns queries etc.
On Thu, Feb 20, 2014 at 2:37 AM, David Fifield david@bamsoftware.com wrote:
On Wed, Feb 19, 2014 at 04:59:05PM -0800, George Kadianakis wrote:
George Kadianakis:
b) You can write your own Python code and selectively steal code from obfsproxy. You will have to steal the code that does networking, Extended ORPort, environment variable parsing (pyptlib), SOCKS, etc. This might not be too hard.
Could the shared code be used to augment pyptlib? I guess Extended ORPort is probably something that all Python pluggable transport implementations might want.
The issue is that by adding an Extended ORPort implementation in pyptlib we would have to select a specific networking library (socket, Twisted, etc.) and the transport author would be forced to use the same networking library.
It's not so clear what the best way to handle it is. We thought about it in the past but didn't come to a clear solution.
If any kind of ExtORPort support is added to pyptlib, I think it makes sense for it to be a Twisted one, because that's what people seem to want to use.
The act of creating a new transport program separate from obfsproxy, that steals as much code from obfsproxy as it needs, could be a good way to identify what ExtORPort functions need to be present in a library and how they need to be generalized. I think it would not be a waste of effort to make a new program with this goal in mind.
golang gets to cheat on the issue because there's really only one way to do concurrent networking in Go. (But also, nobody has used goptlib as much as I have, so it might not be as clear-cut as I think.)
David Fifield _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev