Connection - "First Hop over Tor"

[0x27]

So looking at this, it should be reasonably trivial to do your first hop over Tor, by putting a Tor daemon in the containers, and telling the OpenVPN connection to use the local SOCKS5 proxy offered by the Tor daemon.

The reason I personally think this would be an excellent feature, is in the cases where you don't trust your VPN provider all that much to not immediately give you trouble, or for the ultra-paranoid, etc etc.

[byt3bl33d3r]

+1 this would be amazing

[audibleblink]

Good idea.

Do you see an advantage to having each container connecting through Tor?

What about spinning up a single tor-proxy container within the docker network and pointing the VPN containers at it?

What other advantages do you see having this functionality in the tool vs configuring the docker daemon to use a Tor proxy started on the host?

[0x27]

To be honest, the single-proxy-container setup to do transparent proxying for the VPN containers is probably the best option for performance, the only reason I was thinking of using a proxy-per-container is because it was the first solution that came to mind.

Using the hosts Tor setup is also an option, but it seems there already exists a number of "transparent Tor proxy" Docker images we could use here, and reduces the amount of dependencies required on the host itself.

[audibleblink]

I'm trying this locally, by starting a few different tor proxy containers. I can get curl --proxy ... to go through tor, but openvpn refuses to connect regardless of what I set proto to in the ovpn conf (udp|tcp).

# openvpn logs
#> openvpn --config Japan.ovpn --socks-proxy 172.17.0.2 9050
Thu Apr 19 23:16:17 2018 Attempting to establish TCP connection with [AF_INET]172.17.0.2:9050 [nonblock]
Thu Apr 19 23:16:17 2018 TCP connection established with [AF_INET]172.17.0.2:9050
Thu Apr 19 23:16:17 2018 recv_socks_reply: Socks proxy returned bad reply

tor logs
Apr 19 23:12:55.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 19 23:12:55.000 [notice] Bootstrapped 100%: Done
Apr 19 23:15:44.000 [warn] socks5: command 3 not recognized. Rejecting.

I gave this a few hours while on vacation. Will give it some more time when I get back .

A note on the implementation I'm planning:

IF --up AND --tor
  tor_containter = start_tor_container()
  start_the_rest_and_link(tor_container)

This should add an /etc/hosts entry for tor in each container as well as some ENV vars.

I'll probably have to add a script to the containers and make supervisor call that script. The script will determine whether or not tor is desired based on the existence of the TOR env vars and start openvpn with --socks-proxy tor 9050 as a flag.

I'm trying to not modify the ovpn configs at all.

[BBerastegui]

Hi all,

This is not about this specific issue, but it goes in a similar topic (tell me if you want me to open this in a separate issue).

What about on having the option of just popping multiple containers with Tor docker images and use them as outgoing socks proxies instead of the VPNs?

We can easily build a docker image that will run tor and expose a port that we can put as an exit, like the VPNs are now.

By giving this option, it'll be also possible to run DoxyCannon without the need of having VPNs set up, just by using multiple Tor nodes as exit points 😃

./doxycannon.py --only-tor --nodes 16

That will pop 16 containers with Tor running and the proxy balancing the requests through all those containers.

[audibleblink]

That's an interesting idea. Although Tor exit nodes usually trip captchas on moderately defended services.

WAFs and CDNs are well aware of Tor nodes, which is why I was originally thinking of using Tor just as a filter between your machine and a VPN provder.

The VPN providers are all on clearnet and less likely (though still possibly) flagged and captcha'd.

[BBerastegui]

But why not leave that to the user to choose?

If you are hitting a "normal" website, it's unlikely that they are actively blacklisting Tor nodes, so it could be useful for bypassing API rate limiting or to lose traceability for example :D

[audibleblink]

Yeah, I'm not opposed to it. I'd be happy to merge something like that, especially if it doesn't conflict with the existing functionality. Would you mind filing as a separate issue? I still want the feature where only the first hop is over Tor.