Hello David and George and other people who are interested in there being even more obfuscation transports for tor, I appreciate the thought of making a frankenstein butchering of obfsproxy code which transports tor over dns... and speaks socks and tor control port... and works to PT spec... but what do you think about this: With a relatively small code change it would be possible to make a pluggable system to get obfsproxy to use an external vpn as a bridge transport... Then we can write lots of fun simple vpn transports that spray different kinds of packets... tor over dns being one of the more interesting possible vpn transports... but perhaps tor over icmp would prove useful because nat traversal would be possible... whereas tor over bidirectional syn flood not so much. ;-) When I again looked at pyobfsproxy.py, obfsproxy/managed/server.py, obfsproxy/managed/client.py and obfsproxy/transports/transports.py it occurred to me that we could parse an extra commandline arg to set obfsproxy into vpn mode... calling do_managed_server() and do_managed_client() with an optional keyword arg to set it to vpn mode wherein launch_transport_listener is called in either "vpnclient" or "vpnserver" mode... it looks at the transport options and creates a tun device and perhaps sets the ip to the address specified in the transport options, sets a static route to the run device, etc... Some other process or other reactor listener handles the vpn traffic by reading and writing to the tun device and spraying packets. Looking at launch_transport.py we see that launch_transport_listener would have to change a bit to handle the case where in vpn mode the downstream circuits for both server and client is over the tun device... In vpn mode obfsproxy just proxies over the tun device... and all the obfuscation is handled by the vpn program handling that tun device. I was thinking that perhaps my pony's [1] twisted producer/consumer tun device classes might be useful in making various VPNs suitable to obfuscate tor traffic... the dns vpn being one of the more useful and interesting packet transports. [1] - https://github.com/david415/ponyVPN/blob/master/tun_writer.py https://github.com/david415/ponyVPN/blob/master/tun_reader.py Isis, George, what do you think of these client and server's torrc files for a dns vpn tor bridge? Do tor bridges have to be advertized with a ip:port? I think they do... for tor dns bridges this host and port won't be used... The tor dns bridge operator might want to advertize various transport options that help client's talk to their vpn transport... Given that we have some obfuscation vpn that sprays packets in whatever protocol... (dns, icmp, syn flood ;-)...) I was thinking... a tor client connecting to a tor dns bridge might have a torrc that looks like this. >>---> Log notice stdout SocksPort 8040 DataDirectory ./client-data UseBridges 1v Bridge vpn-ponydns 127.0.0.1:4703 tundevice=tun0 tun_local_ip=10.9.6.1 tun_remote_ip=10.9.6.2 tun_netmask=255.255.255.0 dns_name=my.cute.pony.bridge.dns_root ClientTransportPlugin vpn-ponydns exec /usr/local/bin/obfsproxy --log-min-severity=info --log-file=/var/log/tor/dawuud-obfsproxy/obfsproxy client.log --role=vpnclient managed >..< and the obfsproxy bridge server torrc like this: Log notice stdout SocksPort 0 ORPort 7001 ExitPolicy reject *:* DataDirectory ./bridge-data BridgeRelay 1 PublishServerDescriptor 0 ServerTransportListenAddr vpn-ponydns 127.0.0.1:4703 ServerTransportPlugin vpn-ponydns exec /usr/local/bin/obfsproxy --log-min-severity=info --log-file=/var/log/tor/obfsproxy/obfsproxy-bridge.log --role=vpnserver managed ServerTransportOptions vpn-ponydns tundevice=tun0 tun_local_ip=10.9.6.2 tun_remote_ip=10.9.6.1 tun_netmask=255.255.255.0 dns_name=my.cute.pony.bridge.dns_root ~-~ On Wed, Feb 19, 2014 at 06:37:48PM -0800, David Fifield wrote: > On Wed, Feb 19, 2014 at 04:59:05PM -0800, George Kadianakis wrote: > > > George Kadianakis: > > >> 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. > > > > > > Could the shared code be used to augment pyptlib? I guess Extended > > > ORPort is probably something that all Python pluggable transport > > > implementations might want. > > > > The issue is that by adding an Extended ORPort implementation in pyptlib > > we would have to select a specific networking library (socket, Twisted, > > etc.) and the transport author would be forced to use the same networking > > library. > > It's not so clear what the best way to handle it is. We thought about it > in the past but didn't come to a clear solution. > > If any kind of ExtORPort support is added to pyptlib, I think it makes > sense for it to be a Twisted one, because that's what people seem to > want to use. > > The act of creating a new transport program separate from obfsproxy, > that steals as much code from obfsproxy as it needs, could be a good way > to identify what ExtORPort functions need to be present in a library and > how they need to be generalized. I think it would not be a waste of > effort to make a new program with this goal in mind. > > golang gets to cheat on the issue because there's really only one way to > do concurrent networking in Go. (But also, nobody has used goptlib as > much as I have, so it might not be as clear-cut as I think.) > > David Fifield > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev