[tor-dev] Obfsproxy Address Translation

[Yawning Angel]

On Fri, 16 Jan 2015 16:17:38 +0100
Alfredo Palhares <masterkorp at masterkorp.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150116/0bb486f8/attachment.sig>