By Anonymous

How to access websites hostile toward Tor through Tor

Tor is an effective tool that allows us to access network services anonymously. Unfortunately, certain network services, often websites, have hostility towards Tor and employ various methods to block TCP connections originating from Tor exit nodes. However, they usually accept TCP connections that do not originate from Tor exits.

Therefore, to access these Tor-hostile websites, one approach is to route the traffic through a proxy server after exiting the Tor network. But how can we configure an additional proxy outside of the Tor exit relay?

shadowsocks SIP003 extension

The SIP003 plugin is a program that accepts a series of environment variable parameters and is used to forward a remote TCP server to a local port. When using the SIP003 plugin with a shadowsocks client like ss-local(1), the plugin is executed as a subprocess after setting the environment variable parameters. It then accesses the remote shadowsocks server that has been forwarded to the local port by the SIP003 plugin.

As we know, Tor can function as a SOCKS4, SOCKS4a, SOCKS5, and an HTTP proxy server that supports only the CONNECT method (assuming Tor’s SOCKS proxy server listens on 127.0.0.1:9050, and the HTTP proxy server listens on 127.0.0.1:8118). By utilizing the functionality of these proxy servers to forward a remote TCP server to a local port, we can create a SIP003 plugin based on a proxy server. With this plugin, ss-local can connect to the shadowsocks server through Tor, effectively adding an additional proxy server outside of Tor’s exit. By setting ss-local as the SOCKS proxy server, we can access websites hostile towards Tor.

socat(1) is capable of forwarding a remote TCP server to a local port through a SOCKS4a proxy server. By encapsulating it in a shell script that conforms to the calling conventions of the SIP003 plugin, we can create a SIP003 plugin called sip003-socks.sh based on a SOCKS4a proxy server (the meanings of uppercase environment variables are explained in the referenced SIP003 specification):

#!/bin/sh
socks_host=$(echo ${SS_PLUGIN_OPTIONS} | cut -d: -f1)
socks_port=$(echo ${SS_PLUGIN_OPTIONS} | cut -d: -f2)
exec socat TCP-LISTEN:${SS_LOCAL_PORT},fork,bind=127.0.0.1 SOCKS4A:${socks_host}:${SS_REMOTE_HOST}:${SS_REMOTE_PORT},socksport=${socks_port}

The value of ${SS_PLUGIN_OPTIONS} is obtained from the –plugin-opts option of the shadowsocks client, and it is used here to pass the location of the local SOCKS4a proxy server (i.e., Tor). For example, you can start ss-local with the following command line (assuming /path/to/sip003-http.sh has executable permissions):

ss-local --plugin /path/to/sip003-socks.sh --plugin-opts 127.0.0.1:9050 ...

socat forks subprocesses to handle incoming connections.

Unauthenticated proxy server

In fact, when accessing websites that support HTTPS, adding an extra layer of encryption between the Tor exit and the extra proxy server may not provide significant benefits. Moreover, there are many unauthenticated SOCKS or HTTP proxies available through search engines. Therefore, we can simply forward such proxy servers to our local system using the methods mentioned earlier via Tor.

The proxy server is similar to that of a telephone operator. The caller first communicates with the operator, requesting assistance in connecting to the callee. Once the connection is established, the operator (proxy server) no longer participates in the communication but simply forwards the communication between the caller and the callee. Therefore, the caller can, within the constraints of the network topology, ask the first operator to help connect to the second operator and so on until the final operator connects to the callee.

One can use socat as mentioned earlier to achieve this, but its syntax can be complex and challenging to use without proper encapsulation. Here are some tools with simpler syntax:

For example, simpleproxy(1) is a straightforward TCP reverse proxy that does not directly support SOCKS proxy and has some limitations with HTTP proxy support. However, it can be forced to use a proxy server by injecting a dynamic library through tools like tsocks or proxychains using the LD_PRELOAD mechanism:

proxychains simpleproxy -L ${local_port} -R ${remote_proxy_host}:${remote_proxy_port}

However, a better tool for this scenario is proxytunnel(1), which explicitly supports HTTP proxies and even provides support for chaining two HTTP proxies. Its main purpose is to forward its standard input/output to remote server through one or two proxy servers. When used in conjunction with OpenSSH’s ProxyCommand option, it enables SSH to traverse through proxy server(s). However, using the -a or –standalone option of proxytunnel allows it to listen on a local port and forward the remote server through an HTTP proxy to the local system. It also forks subprocesses to handle incoming connections.

proxytunnel -a ${local_port} -p 127.0.0.1:8118 -d ${remote_proxy_host}:${remote_proxy_port}

Based on the chosen type of extra proxy server (HTTP or SOCKS), the client can then access Tor-hostile target websites through the forwarded extra proxy server by connecting to 127.0.0.1:${local_port}, where ${local_port} is the local port to which the traffic is forwarded.

If you prefer not to have these forwarders occupying the terminal, you can use daemon(1) to execute them as background processes.

Of course, proxytunnel can also be used to implement a SIP003 plugin, sip003-http.sh, which achieves forwarding through an HTTP proxy:

#!/bin/sh
exec proxytunnel -a ${SS_LOCAL_PORT} -p ${SS_PLUGIN_OPTIONS} -d ${SS_REMOTE_HOST}:${SS_REMOTE_PORT}

To test the availability of an extra proxy server and identify malicious servers that may perform a man-in-the-middle attack

Proxy servers found through search engines may not always be reliable. Additionally, the author has discovered that some proxy servers provide untrustworthy certificates, indicating that these servers launch man-in-the-middle attacks on users. Therefore, it is crucial not to blindly trust proxy servers found through search engines and to test them thoroughly before using them.

Firstly, you can use a proxy-aware nc compatible tool to test whether these proxy servers can establish connections through Tor:

nc.openbsd -zx 127.0.0.1:9050 ${remote_proxy_host} ${remote_proxy_port};echo $?

If you are using ncat, you can use the following command line:

ncat -z --proxy-type socks5 --proxy 127.0.0.1:9050 ${remote_proxy_host} ${remote_proxy_port};echo $?

The command echo $? displays the return value of the previous command. When using nc -z, a return value of 0 indicates a successful connection, while a return value of 1 indicates a failure. Therefore, an output of 0 confirms that the proxy server can be connected through Tor.

Next, you can use the previously mentioned method to forward the proxy to ${local_port}, and then test it using curl assuming you have selected a SOCKS5 proxy server:

curl -vx socks5h://127.0.0.1:${local_port} https://wtfismyip.com/json

By using “socks5h” to specify the proxy server, the target host’s domain name will be passed to the proxy server. On the other hand, using “socks5” will resolve the domain name locally and pass the target host’s IP address to the proxy server.

If, after forwarding the proxy to the local system, you receive an untrusted certificate, whereas accessing the target directly through Tor gives you a trusted certificate, it indicates that the proxy is performing a man-in-the-middle attack. In such a case, it is advisable to refrain from using that proxy and choose an alternative option.