SOCKS connection establishment explained

There is a really good explanation of everything that happens during a HTTP-request that is relayed through a SOCKS5-proxy here. Nonetheless, I decided to make a similar post mostly in order to really figure it out myself. So here it goes.

I ran a little SOCKS5-server on my machine on port 8123. I then configured Firefox to use 0.0.0.0:8123 as a SOCKS-proxy and enabled the "remote DNS"-function. After that, I opened a website. During all this, I let wireshark capture the loopback device. If you want to see what kinds of values the different fields can take, the wikipedia article lists them all. The RFC is also pretty short and gives some more detailed explanations.




1. Packets 1 - 3: 
The first 3 packets are a standard TCP-3-way-handshake. Nothing special about that. Firefox chose port 54918 in order to open the connection.

2. Packets 4 & 5:
Packet 4 is the initial greeting by the client, (method selection message). It contains 3 fields, each one byte long. In my case it looks like this (click on the image if it's to small):

Wireshark classifies the last 3 bytes as TCP segment data. They are in fact the SOCKS-fields:

Initial SOCKS-client greeting

What this says is that we use SOCKS version 5, there is one authentication method supported by the client and this authentication methond is "no authentication".

There could also be more than one authentication method supported by the client. In this case the number of "Authentication method"-fields would reflect the number given in field two.

Packet 5 is just the ACK by the server.

3. Packets 6 & 7:
Packet 6 is the servers method selection response. The server chooses one of the given authentication methods and tells the client about this choice. As there is only one authentication method supported by the client in our case, the server had to chose that one. The corresponding wireshark trace:

Again the last bytes are classified as TCP segment data. This time, there are only two fields:

Server's choice

Pretty self-explanatory: The server chooses the only available authentication method - no authentication.

Packet 7 again just is the ACK, this time by the client.

4. Packets 8, 9, 10 & 11
Now it gets interesting (and maybe a bit confusing). Remember that I enabled "remote DNS" in Firefox. This is now coming into play.

Packet 8 is the client's connection request. It tells the SOCKS-server, that it is supposed to establish a TCP-connection to a server. The "remote DNS" setting ensures, that the client does not try to resolve domain names itself. First, the wireshark capture:

I'll first explain the SOCKS-content of packet 8. It looks like this:

Client's connection request

The command code can be "connect" (=0x01), "bind" (=0x02, used for things like ftp) or "udp associate" (=0x03). The address type could also be 0x01 (IPv4) or 0x04 (IPv6). If I had not enabled "remote DNS", the client would have resolved the address by itself and then sent a connection request with address type 0x01. As both client and server are running on the same machine here, we do see the DNS-messages. Don't be fooled, they are initiated by the server!

(Just to be sure I ran the SOCKS-server on my Raspberry Pi and tried it again - worked exactly as expected! I decided to keep this capture here, because it shows all messages.)

So packets 9 and 10 are just DNS-messages sent and received by the server. And packet 11 is just the ACK for packet 8.

Packet 12 (& 14):
The server now has resolved the domain name and established a TCP-connection to the corresponding webserver. This can not be seen in the capture, as I do not capture the eth0-device. The DNS-request was only captured because it was internally sent to the DNS-resolver. The SOCKS-server now has to inform the client about the fact that the connection is established by sending a connection response. The capture:

Content of the SOCKS-packet:

Server's connection response

This tells the client where it should direct the following traffic. A socks server could transmit a different IP and port than was used for establishing the connection. In my case, it didn't. The reply filed value "00" stands for "succeeded" and the address type "01" again for IPv4.

Packet 14 is the ACK for this packet.

Packet 13, 15 and following:
The following packets don't contain any special SOCKS-fields anymore. The client just sends the HTTP-requests to the IP:port-combination given in the server's connection response (here: 127.0.0.1:8123). The server takes the request (the "TCP segment data") from the clients message and sends it on to the webserver with which it established a connection. The replies are relayed by the SOCKS-server to the client - it takes the data sends it to the client.