[tor-dev] obfsproxy dns transport

[George Kadianakis]

>>
>>
>> George,
>>
>> I'd like to write a dns transport... and it seems to me the
>> obfsproxy api isn't designed for non tcp transports...
>> Maybe we again make some changes to the obfsproxy api?
>> It would transport IP packets using a tun device...
>> we can route it to a socks endpoint and proxy from there.
>>
>> I think there is a whole class of obfuscated transports that could
>> benefit
>> from an obfsproxy plugin interface for vpns... transports that use a tun
>> interface...
>>
>> I'll have to take a closer look at the obfsproxy api and think about
>> this
>> some more.
>> I was just curious to see if you had any thoughts on the subject.
>>
>> There is this interesting code to learn about dns transport here:
>> https://code.google.com/p/dnscapy/
>> it uses the scapy automatom api instead of twisted. Could easily be
>> ported
>> to twisted I think.
>>
>> Feel free to forward your response to the tor-dev mailing list.
>> No hurry. No worry.
>>
>> Cheers!
>>
>> David
>>
>
> Hello David!
>
> I won't be able to answer thoroughly atm since I'm at the dev
> meeting. I will be back home soon and be able to answer more smoothly.
>
> In general, a DNS transport would be great! A well designed DNS
> transport would be a PITA to block and would also work in most
> networks (even through captive portals etc.).
>
> The short answer is that obfsproxy is indeed not designed to
> facilitate PTs like DNS transports. It will probably require a
> considerable refactor of obfsproxy to write a DNS pluggable
> transport. It will probably require so much refactoring that I'm not
> sure if it would make sense to merge the changes back upstream
> (because the changes might not be useful for other PTs).
>
> The main reason you want to use obfsproxy is so that you don't have to
> write your own SOCKS code, or your own Extended ORPort code, or your
> own PT-protocol code.
>
> That said, here are two other approaches you can take:
>
> a) You can "fork" obfsproxy, perform your changes, and then we can
>    deploy your fork as a standalone PT. Since obfsproxy's architecture
>    is designed to support multiple PTs you might have to perform
>    considerable changes to obfsproxy; but that's fine, since you will
>    be the only one using that fork of obfsproxy.
>
>    A small problem with this approach is that we will have to deploy
>    two obfsproxy codebases which will increase the size of the
>    bundle. The good news is that the size of the obfsproxy codebase in
>    the latest TBBs prepared by David is only 350Kb which is not too
>    much even if doubled.
>
> 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.
>
>    Alternatively you can use Go, and use David's goptlib library [0]
>    which does both Extended ORPort and SOCKS.
>
> Also, before you start writing code, it might be worth looking at the
> pt-spec and seeing if it can support DNS PTs as it is.
>
> BTW, do you know of any censorship circumvention tools that use DNS as
> a covert channel?
>
> [0]: https://gitweb.torproject.org/pluggable-transports/goptlib.git
>

FWIW, people told me that Freenet has had a DNS transport for ages.
There is also this:
https://lists.torproject.org/pipermail/tor-talk/2006-January/007124.html