SOCKS5 - Connection authentication

Question

I am trying to implement reverse SOCKS5 according to RFC1928. I have a relay server which runs passively waiting for connections from the SOCKS5 client which acts a proxy, and the the client which wants to use the tunnel.

Legend

Server (10.211.55.6) = Relay = PC 1 (send/recv)

Client_1 (10.211.55.10) = Proxy (running on another PC in my network)

Client_2 (10.211.55.8) = Tunneller (connecting from MaxThon Browser (since it allows SOCKS5 authentication))

Execution flow

1. Client_1 connects to Server on port 9444
2. Server finds an unused port and binds to it (lets say port 13451 is opened)
3. Client_2 connect to Server on port 13451
4. Server accepts the connection and now relays the traffic between Client_1 and Client_2
5. Client_2 sends the SOCKS5 protocol (according to RFC1928) requests to Client_1 relayed through Server
6. Client_1 authenticates and gets a CONNECT command to https://dnsleaktest.com and sends back a status_ok response
7. The packets from the webpage are received, and the webpage is loaded

Problem

8. Client_2 wants to connect to another webpage (lets take https://packetstormsecurity.com for example).

Question

Client_1 only receives a few packets from Client_2 such as \x17\x3\x3 or \x17\x3\x3\x1 (what do these bytes represent?). Does Client_1 have to go through the SOCKS5 authentication again, or how would it process the request to the new webpage?

Side Notes

A) After a while, the page that Client_2 requested from Client_1 returns ERR_TIMED_OUT in the browser, since Client_2 didn't get any response. But if its expecting a response, then its also assuming that I know how to parse the bytes that it sends, but I don't know what they are as I haven't seen them in the RFC1928 documentation.

Answer 1

Client_1 only receives a few packets from Client_2 such as \x17\x3\x3 or \x17\x3\x3\x1 (what do these bytes represent?).

Client_2 is requesting tunnels to HTTPS hosts. What you are seeing are TLS 1.2 packets between Client_2 and the HTTPS server, after the SOCKS tunnel to the HTTPS server has been established:

\x17 = content type (#23, application data)
\x03 = major version 3
\x03 = minor version 3
\x01 = fragment length (1 byte)
...

Does Client_1 have to go through the SOCKS5 authentication again

Once a SOCKS tunnel has been established, everything that is transmitted through that tunnel is application-defined data. As such, there is no way for a SOCKS client to send a new SOCKS command over an existing TCP connection. That means Client_2 must create a new TCP connection to your Relay Server (and thus to Client_1) in order to request a new SOCKS tunnel to a different host, and that involves a new SOCKS authentication handshake, yes (even if SOCKS were not involved, Client_2 would have to establish a new TCP connection to the new host anyway).

or how would it process the request to the new webpage?

Client_1 would have to wait to accept a new TCP connection from Client_2 (or any other client) before it could process a request for a new SOCKS tunnel.

After a while, the page that Client_2 requested from Client_1 returns ERR_TIMED_OUT in the browser, since Client_2 didn't get any response.

Then either the HTTPS server is not responding to Client_2's HTTPS request, or more likely Client_1 has a logic bug in its handling of the SOCKS tunnel and is not relaying the HTTPS server's response data to Client_2.

But if its expecting a response, then its also assuming that I know how to parse the bytes that it sends, but I don't know what they are as I haven't seen them in the RFC1928 documentation.

Once Client_1 has established a SOCKS tunnel, it is not supposed to parse anything transmitted through that tunnel (unless the SOCKS authentication scheme that you negotiated requires encapsulation of transmitted data). Data transmitted through a SOCKS tunnel is application-defined, so only the client and target server on both ends of the tunnel know what the data actually is. Client_1 must relay as-is (handling encapsulation if needed) whatever raw data it receives in both directions (just as your Relay Server does).