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