We technically don't need to use a tun device for the dns transport... but if a tun device is used for the tor dns transport then we get the reliability layer without having to write it ourselves. It doesn't matter that tun devices are lossy and udp is unreliable; we just spray packets. Obfsproxy has it's transport's circuit.downstream tcp connection routed over the tun device; tcp takes care of congestion control, retransmission etc. I think it might also be useful to get a simple udp vpn working as an obfsproxy transport... it could listen on various ports... including udp port 53 which is sometimes accessible from within captive portals... and would be much faster than tunneling over dns. Quicktun http://wiki.ucis.nl/QuickTun seems like a sufficiently simple and cool (uses nacl's curve25519xsalsa20poly1305 crypto-box) vpn that might work well with an obfsproxy vpn plugin system... i kinda like how it's crypto can be turned off so that it passes the raw data over udp ;-) It also seems like it would be easy to combine any existing obfsproxy transports with the obfsproxy vpn mode.... by having an existing obfsproxy transport class obfuscate the payload before passing it to the circuit's downstream tcp connection which is routed over the tun device. Here's a few vpn + transport combinations that might be interesting: dns(udp-tun(ip(tcp(tor)))) dns(udp-tun(ip(tcp(bananaphone(tor))))) udp-quicktun-nacltai(ip(tcp(tor))) udp-quicktun-raw(ip(tcp(scramblesuit(tor)))) dns(udp-tun(ip(tcp(scramblesuit(tor)))))
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev