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