[tor-dev] obfsproxy dns transport

[David Stainton]

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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev