How Socks 5 Works

Introduction to Socks

Socks is a protocol that allows a client to make network connections through a proxy server. This is useful to bypass firewalls and Internnet content filters, and to conceal a client's IP address.

Socks operates at level 5, the Session layer.

For a much more complete explanation, see this excellent Wikipedia page :

I decided to examine Socks in action, in particular, Tor, the anonymity system.

This page shows a complete HTTP request and through the Tor network from the client side.

Installing Tor

I installed Tor on a Windows 8 Developer Preview virtual machine, using this procedure:

The Vidalia client connects, and Firefox gets a TorButton, showing as a little green onion icon to the left of the URL, as shown below:

Sniffing from the Loopback Interface

The Tor proxy listens on However, Wireshark cannot sniff packets on the loopback interface in Windows 8, so I used RawCap instead.

After starting RawCap, I opened in Firefox, through Tor.

I opened the pcap file in Wireshark, searched for the string "astalavista", filtered for that TCP stream, and saved just that stream as a new pcap file.

The pcap of that TCP stream is here:


You may want to download it, open it in Wireshark, and follow along.

Packets 1-5: TCP Handshake and Greeting from Client

Packets 1-3 are the TCP handshake, SYN, SYN/ACK, ACK, establishing a connection from to the Tor proxy at

Packet 4 is a "Greeting from Client", with only three bytes of data:

Packet 5 is the ACK from the Tor proxy, indicating that it received the Greeting packet.

Packets 6-7: Server's Choice

Packet 6 is a "Server's Choice", of authentication method. There are only two bytes of data:

Packet 7 is the ACK from the client, saying that it received the "Server's Choice" packet.

Packets 8-9: Client's Connection Request

Packet 8 is the "Client's Connection Request", containing this data:

Packet 9 is the ACK from the proxy server, saying that it received the "Client's Connection Request" packet.

Packets 10-11: Server Response

Packet 10 is a "Server Response", containing this data:

Packet 11 is the ACK from the client, saying that it received the "Server Response" packet.

Packets 12-13: HTTP GET

Packet 12 contains a complete HTTP GET request, sent to

Notice that Wireshark does not understand this packet, because it is not a normal HTTP packet sent to the server on port 80. Wireshark just sees it as a raw TCP packet for an unknown protocol.

The local host doesn't even know the IP address of, or care. The proxy will fetch the layer 7 data and deliver it to the established session.

Packet 12 is the ACK from the server, saying that it received the "HTTP GET" packet.

Packets 14-19. HTTP Rensponse and Session Teardown

Packet 14 is an HTTP reply. Since this page has moved, the reply is small enough to fit into a single packet. And, once again, Wireshark is unable to understand the data because it is not a normal HTTP reply sent directly from the server's port 80.

Packet 15 is the ACK from the client, saying that it received the HTTP reply packet.

Packets 16-19 are FIN handshakes, terminating the TCP session.


Last modified: 11-16-11 3 pm

Written by Sam Bowne