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