Censorship Explained: Shadowsocks

In the early 2010s, a simple tool thrown together by a lone programmer ignited an explosion of anti-censorship activity. Over the next decade, that simple tool–Shadowsocks–spawned a vast ecosystem of tools and techniques, developed by thousands and relied on by millions. We’ll need a firm grasp on how Shadowsocks works under the hood to better understand its modern relatives like VMESS and Xray. Let’s get started!

The SOCKS in Shadowsocks

The Shadowsocks author, Chinese developer “clowwindy”, described it as “a fast tunnel proxy”. Its name comes from its reliance on a specific type of proxy, SOCKS.

What exactly is a proxy? One way to think about your computer’s internet connection is like a bundle of pipes, each carrying data to and from a different place. The pipes all go the same direction at first (toward your ISP), then branch off to reach their respective destinations.

With a proxy, we build a pipe from our computer to an intermediate destination, the “proxy server”, then ask the proxy server to build a second pipe to our actual destination. Once both pipes are set up, the proxy server passes data from one to the other. Together the two pipes and the proxy server act like one long pipeline connecting our computer to the destination.

Obviously it is easier to build a single, direct pipe between our computer and the destination. But sometimes that isn’t possible, such as when:

• a firewall blocks direct pipes from our computer to the destination
• the destination refuses to accept pipes from our computer
• we don’t want the destination to know the pipe is from our computer

How does your computer tell the proxy server what kind of pipe to build? It must communicate using a specific language, the “proxy protocol”, that the server understands. There are many different protocols, of which SOCKS is one of the oldest, simplest, and most widespread.

SOCKS Proxy Protocol (Simplified)

1. Client sends an initial message with a SOCKS version number and a list of authentication methods.
       “I’m using SOCKS Version 5 and I can authenticate with a password or key”
2. If the proxy is using the same SOCKS version and supports any of the authentication methods, it responds by selecting one supported method. Otherwise it returns an error.
       “Ok, let’s authenticate with a password”
3. Client and proxy exchange authentication details as specified by the chosen method. If authentication fails, the proxy returns an error.
4. Client sends a request telling the proxy which destination to build a pipe to.
       “Please set up a proxy pipe to Wikipedia”
5. If the proxy is able to create the pipe it sends a confirmation. Otherwise it returns an error.
       “Ok, the pipe is ready”
6. The proxy begins passing outgoing messages from the client to the destination, and incoming messages from the destination to the client.
7. This continues until one of the two pipes is destroyed (when the client or destination end the connection). Then the proxy destroys the other pipe as well.

Hiding the SOCKS Conversation

The reason SOCKS isn’t a good circumvention tool on its own is that the protocol conversation between client and proxy takes place “in public”. A firewall located between client and proxy can listen in on the conversation, and firewalls designed for censorship will simply block SOCKS connections to prevent people from using proxies to get around restrictions.

Shadowsocks fixed this problem by splitting the SOCKS conversation into three parts: the first takes place entirely on the client, the second is an encrypted conversation between client and proxy, and the third takes place between the proxy and the destination server. In terms of our pipe analogy, Shadowsocks adds a third pipe between the two segments of the SOCKS proxy pipeline.

This three-pipe design turned out to be extremely powerful. The two pipes on the outside use the well-known, reliable SOCKS protocol to connect client apps on one end to destination servers on the other. Neither pipe crosses the firewall, so the public SOCKS conversation is not exposed.

The middle pipe, meanwhile, does cross the firewall and can be observed. But the three-pipe design makes the middle pipe extremely customizeable. Different connection types or encryption methods can be used for the middle pipe without affecting how the outer two pipes interact with client apps or destination servers.

Shadowsocks Protocol (Simplified)

1. Client app sends a SOCKS message to the Shadowsocks client.
2. Shadowsocks client encrypts the message, then sends it to the Shadowsocks proxy.
3. Shadowsocks proxy decrypts the message and processes it according to the standard SOCKS protocol.
4. To send back a SOCKS reply, the proxy first encrypts its reply, then sends it to the Shadowsocks client.
5. Shadowsocks client decrypts the reply and forwards it to the client app.
6. Client app processes the reply according to the standard SOCKS protocol.

Deleted But Not Forgotten

Three years after its initial release, the Shadowsocks project came to an abrupt end when “clowwindy” announced he had been contacted by police and told to delete the project.

Yet the effectiveness of Shadowsocks’ three-pipe proxy design spurred a flurry of innovation focused primarily on the key middle pipe. Circumvention tool developers explored ways to make the middle pipe harder to detect and harder to block. Censors (with China’s Great Firewall leading the way) followed close behind, rolling out new methods of detecting and shutting down suspected middle pipes.

In the next article we’ll look at two early particpants in this race: ShadowsocksR and V2Fly. We’ll also discuss how the many Shadowsocks-compatible clients bundle up various protocols to link end users with proxy servers.

Thanks for reading! If you have any questions, corrections, or suggestions, please shoot me an email or find me on Reddit. If you’re looking for a simple, “no configuration needed” way to get around censorship in countries like China, Iran, and Russia, then please give Wallpunch a try!