[tor-dev] obfsproxy dns transport
desnacked at riseup.net
Thu Feb 20 01:00:09 UTC 2014
>> 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
>> from an obfsproxy plugin interface for vpns... transports that use a tun
>> I'll have to take a closer look at the obfsproxy api and think about
>> 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:
>> it uses the scapy automatom api instead of twisted. Could easily be
>> to twisted I think.
>> Feel free to forward your response to the tor-dev mailing list.
>> No hurry. No worry.
> 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 
> 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?
> : 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:
More information about the tor-dev