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 :

http://en.wikipedia.org/wiki/SOCKS

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:

https://www.torproject.org/docs/tor-doc-windows.html.en

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 127.0.0.1:9050. However, Wireshark cannot sniff packets on the loopback interface in Windows 8, so I used RawCap instead.

http://www.netresec.com/?page=RawCap

After starting RawCap, I opened http://astalavista.com 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:

Tor-stream.pcap.

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 127.0.0.1:8678 to the Tor proxy at 127.0.0.1:9050.

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

Socks version number: 5
Number of authentication methods supported: 1
Authentication method: 0 (No authentication)

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:

Socks version number: 5
Authentication method: 0 (No authentication)

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:

Socks version number: 5
Command code: 1 (Establish a TCP stream)
Reserved: always 0
Address type: 3 (domain name)
Length of domain name: 0x0f (fifteen bytes)
Domain name: ASTALAVISTA.COM
Port number: 0x50 (Port 80, HTTP)

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:

Socks version number: 5
Status 0: Request Granted
Reserved: always 0
Address type: 1 (IPv4)
IPv4 Address: 00 00 00 00 (I don't know why this is zeroes, but since the proxy will do the DNS resolution and fetch the page, there is no real need for the local host to know the IP address of the destination machine at all, so this is apparently just dummy data.)
Port number: 00 00 (Apparently also a dummy value)

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 127.0.0.1:9050.

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 Astalavista.com, 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.

Sources

http://en.wikipedia.org/wiki/SOCKS

https://www.torproject.org/docs/tor-doc-windows.html.en

http://wiki.wireshark.org/CaptureSetup/Loopback

http://www.netresec.com/?page=RawCap

Last modified: 11-16-11 3 pm

Written by Sam Bowne