ssl.md

In 2013—2 years before Victoria Raymond began developing V2Ray and 7 years before another project I’ll introduce (in a later blog post) was released—the original creator of Shadowsocks, clowwindy, had already written “ssl.md”, a very brief GitHub Gist explaining why he believed SSL/TLS shouldn’t be used to bypass the firewall.

He believed that a proxy protocol should achieve two things: first, “preventing detection of which websites the client is visiting,” and second, “preventing detection that the server is providing circumvention services.” He argued that because SSL/TLS contains “identity information,” it makes it easier for censors to not only discover proxy servers but also to specifically block all other proxies using the same certificate, even if their IP addresses haven’t been found. (While this argument might sound a bit odd now, you have to remember that Let’s Encrypt hadn’t launched yet back then, and getting a TLS certificate was still a very manual process that could involve linking personal information!)

As the “father of open-source proxy protocols”, clowwindy’s words carry a certain weight within the open-source community. The evolution of Shadowsocks and V2Ray’s VMess protocol during that long period reflects this: the community continuously improved these protocols to prevent connections from being identified as much as possible, almost to the point of obsession, yet TLS was completely left out of the picture. In that “golden age” when traditional VPN protocols with obvious signatures like OpenVPN and IPSec could still be used occasionally, these protocols were seen as an expression of “geek spirit”. Using them usually meant setting them up yourself or finding obscure providers, and then installing software that most people had never heard of at the time. For those who still preferred “big names” like ExpressVPN and Private Internet Access, this wasn’t an easy pill to swallow.

“Random” Becomes Pattern

However, just as users of Shadowsocks and VMess were still immersed in the joy brought by a free internet, the GFW had quietly undergone a qualitative shift: not only had its deep packet inspection (DPI) capabilities significantly improved, but its blocking strategy had also completely changed. Simply put, the conditions for a proxy protocol to survive had suddenly shifted from “not looking like circumventing the firewall” to “looking like a legitimate internet application”.

Since then, in a country that is “self-sufficient” in everything from shopping platforms to niche forums, no matter how elegant Shadowsocks and VMess were, they could no longer justify an ordinary Chinese person transmitting data to unknown overseas servers using an “unidentified” protocol! In the five to six years following the release of Shadowsocks, everyone’s idea was to minimise the characteristics of proxy protocols as much as possible, making the traffic look chaotic and disorganised. No one expected that randomness itself could one day also become a kind of “pattern”.

So, what sort of thing has a regular “pattern”, yet can hold endless “randomness”?

TLS!!!!!

TLS has become an internet default. It is a communication protocol with highly distinctive characteristics, and the handshake phase contains quite a bit of plaintext information (such as SNI, which is also why censors can still block websites); however, once the connection is successfully established, whatever the two parties wish to transmit within the encrypted channel is no longer anyone else’s business.

At this point, you might be thinking: doesn’t V2Ray also provide a Stream that lets you wrap VMess payload inside a TLS channel? Yes, and that is exactly what VMess users rushed to do when they first scrambled to bring TLS to the rescue. As for Shadowsocks, a protocol that inherited clowwindy’s “endowment”, it was well and truly caught off guard. The community had no choice but to develop the V2Ray plugin (which I expressed distaste for in the previous post) to allow Shadowsocks traffic to be hidden in the same way, just to keep it alive.

However, do you see the problem with this approach? I don’t know how powerful the average person’s phone or computer was around 2018, but I’m very clear on one fact: the TLS channel itself is encrypted, and the VMess or Shadowsocks data being transmitted inside it is also encrypted. This double layer of encryption and decryption is a massive waste of device performance and makes connection latency far from ideal. At the time, someone must have been thinking: since the TLS channel is already secure, why not just transmit the proxy traffic directly inside it, instead of lugging around all this historical baggage that only existed because TLS wasn’t being used in the first place?

Here Comes the Trojan Protocol

This is the context in which the Trojan protocol was born. Its principle is so incredibly simple that it came as a wake-up call, completely overshadowing the “old craftsmen” and their meticulously polished designs!

Of course, this simple protocol also comes with a noteworthy feature: its camouflage. When a Trojan server communicates with a non-Trojan client, its behaviour is identical to that of a standard NGINX server. It can also work alongside web servers like Caddy to ensure that, unless a Trojan client is connecting, it appears to be nothing more than a normal website.

To Be Honest

You see, I have managed to introduce the protocol itself in just a few sentences. You know what? When I first realised that planning to write a blog post about this protocol was actually digging a hole for myself, I was genuinely so annoyed that I dragged trojan.md straight into my computer’s recycle bin. But thinking it over carefully, I realised that wasn’t right; as a profoundly enlightening creation against the traditional thinking embedded in Shadowsocks and V2Ray, it deserves to leave a glorious chapter in this history of fighting censorship!