[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