On Fri, 16 Jan 2015 16:17:38 +0100 Alfredo Palhares <masterkorp@xxxxxxxxxxxxxx> wrote: > > My thoughts on the matter are: > > > > 1. This should work. If it can be shown to be broken via a trivial > > application/test case (Eg: netcat), then it should be fixed > > (The trival test case requirement is because I don't want to > > debug OpenVPN again). > OK, what would be the best way to present this data? The easiest quick and dirty one off test I can think of for something like this would be (Using the same hostnames as the example e-mail, fill in the ports to taste): c.example.com: $ obfsproxy --log-min-severity=debug \ > --log-file=/tmp/obfsproxy-client.log \ > obfs3 socks 0.0.0.0:CPORT s.example.com: $ obfsproxy --log-min-severity=debug \ > --log-file=/tmp/obfsproxy-server.log \ > obfs3 --dest vpn.example.com:NPORT \ > server 0.0.0.0:SPORT vpn.example.com: $ nc -l NPORT client: $ nc -x c.example.com:CPORT s.example.com SPORT Typing into either netcat session should send bytes to the other side, on each newline (the newline requirement is due to the TTY code), and has nothing to do with obfsproxy. Naturally c.example.com:CPORT, s.example.com:SPORT and vpn.example.com:NPORT must allow incoming TCP/IP connections. If this doesn't work, c.example.com:/tmp/obfsproxy-client.log and s.example.com:/tmp/obfsproxy-server.log should have enough information to investigate further. Make sure that there is no sensitive information in either logfile, and attach it to the ticket along with the exact commands used on each host. If this does work, you are on your own from that point, because obfsproxy is doing exactly what it is supposed to do (relaying data). > > 2. Oh god, c.example.com is going to be running a public SOCKS > > proxy. Granted people trying to use it to get to most destinations > > will have a connection that fails, but bad people can use it as a > > DDoS amplification host (The SOCKS dialog is much much shorter than > > any of the client requests that would be sent). > The SOCKS proxy will not be public far from that. > The advantage on that is that I setup SOCKS proxy on the best location > that for international traffic. On this specific country international > traffic is very hard from most locations, just because the whole > censorship infrastructure can't deal with all the traffic. Having the > possibility to set it remotely would save work on deploying obfsproxy > trough the OpenVPN clients and to set up yet another HTTP proxy in > between the proxies. This sounds "public" to me, but ok, I'll take your word for it. Regards, -- Yawning Angel
Attachment:
pgpq2cNhqlD4e.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev