1

Although this looks like a bug, some developers argue how it complies perfectly with the RFC.

I wrote a simple C++ program on Linux which connects to a HTTP web-page and reads its contents over Tor. I start a tor service using this command:

tor --ignore-missing-torrc -f / --SocksPort auto --DataDirectory $HOME/tren/tor_0

$HOME/tren is just a directory I mount as tmpfs (btw, the same happens even if I only run tor). Tor connects successfully and I can use its socket. Now my program negotiates with the port like this:

I send {5,1,0}
SOCKS5 sends {5,0}
I send {5,1,0,3,17,www.icanhazip.com,0,80}
SOCKS5 sends {5,0,0,1,0,0,0,0,0,0}

This domain name address is written byte by byte, without null termiation. Why is my SOCKS5 responding with 0 address? If I connect to the web-site using it's IPv4 that I resolve locally, the same happens. I try requesting HTTP page and it responds properly.
I am using Arch and I have installed it's official tor package.

EDIT: I deleted my code as it was incomplete and far from 'minimal'

Halid Beslic
  • 1
  • 5
  • What is the code your question is about? For programming questions, it's also useful to include a [mcve]. Please, as a new user here, read [ask] and take the [tour]. Also, make sure you read and understand the description of the tags you applied. – Ulrich Eckhardt Jun 25 '22 at 10:43
  • @UlrichEckhardt There is not much about the code, the code just does the conversation that I described, but I will include it now that you asked. – Halid Beslic Jun 25 '22 at 10:45

1 Answers1

1

Your SOCKS5 request is perfectly fine, and the proxy is replying back that it successfully connected to www.icanhazip.com:80, so just start exchanging your HTTP data as needed over your existing connection to the proxy.

The proxy's reply is simply telling you that it bound itself to 0.0.0.0:0 (or maybe it is choosing not to tell you the actual IP/port it is bound to) when it connected to www.icanhazip.com:80:

                       BND.ADDR/BND.PORT
                              |
                              \/
+--------+          +-------+          +--------+
| Client | x <-> p1 | Proxy | p2 <-> y | Target |
+--------+          +-------+          +--------+
                        ^
                        |       +-----+
                        +-----> | DNS |
                                +-----+

The zeros you are referring to are in the BND.ADDR/BND.PORT fields of the proxy's reply. Those fields represent p2 above - the outbound IP/Port used by the proxy to connect to the target server after it resolved the hostname that your client requested. It sounds like you are expecting those fields to contain the inbound IP/port for the target server at y instead, which is not the case.

You don't need to know the target's IP/Port in order to use the connection. You have a fully functional tunnel between you and the target via the proxy, just use the connection as-is once the tunnel is established. You just won't be able to know the target's IP/Port. You can't get that info from the proxy. The only way to get it is to either resolve the hostname yourself (which defeats the purpose of asking the proxy to resolve it for you), or else ask the target itself (if it has a script for that purpose).

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Thank you for explaining it! I understand now why it happens. It's unfortunate because I was devising some system and I was assuming that I can know the peer's address. Looks like I'll have to move to socks4 or think more. – Halid Beslic Jun 28 '22 at 13:42
  • "*I was devising some system and I was assuming that I can know the peer's address*" - if by "peer" you mean the target server, then the `BND.ADDR` field in the SOCKS reply is NOT the peer's address, it is the IP that the proxy itself is bound to when it connects to the peer. I updated my answer to reflect this. – Remy Lebeau Jun 28 '22 at 15:55