In this article we're doing deep dive into the Trojan proxy and discover together the inner workings of this protocol which allows you to bypass even the strictest internet censorships or firewalls out there.
In this article we're doing deep dive into the Trojan proxy and discover together the inner workings of this protocol which allows you to bypass even the strictest internet censorships or firewalls out there all due to a clever tactic applied when a connection is being applied. There is nothing new in terms of cryptography or protocol inner workings. In fact, from a technical standpoint, Trojan looks very similar to Shadowsocks proxies and is even less secure inside the pipe, at the packet level, but that's what makes it stealth.
The Trojan proxy has a lot of advantages over other types of proxies and they allow it to bypass censorship with great ease. You would connect to it on port 443 which is the https port and since regular http traffic on port 80 (unsecured, without encryption) is heavily discouraged nowadays, I can say that the majority of internet traffic is done on port 443 which makes the Trojan proxy traffic appear as https traffic. If there's one thing you would take from this entire article is this one: Trojan traffic is indistinguishable from regular https traffic.
Authentication is done using a key. The key is not an encryption key and you may think of it as an API key. A Trojan proxy server would accept connections on a TLS port and, once connection is established, extract the first 56 bytes which should represent the hex(SHA224(key)) encrypted key. SHA224 basically creates a hash of fixed length from the key which is then transmitted as the first payload in order to authenticate the user. The server then compares the known key with the user-submitted key and decides what to do next based on the result. Once authenticated, the traffic starts to flow bi-directionally in a SOCKS5 style request.
+-----------------------+---------+----------------+---------+----------+| hex(SHA224(password)) | CRLF | Trojan Request | CRLF | Payload |+-----------------------+---------+----------------+---------+----------+| 56 | X'0D0A' | Variable | X'0D0A' | Variable |+-----------------------+---------+----------------+---------+----------+where Trojan Request is a SOCKS5-like request:+-----+------+----------+----------+| CMD | ATYP | DST.ADDR | DST.PORT |+-----+------+----------+----------+| 1 | 1 | Variable | 2 |+-----+------+----------+----------+where:o CMDo CONNECT X'01'o UDP ASSOCIATE X'03'o ATYP address type of following addresso IP V4 address: X'01'o DOMAINNAME: X'03'o IP V6 address: X'04'o DST.ADDR desired destination addresso DST.PORT desired destination port in network octet order
If the authentication key does not match, let's say someone is accessing the server via https by using a browser, the server should consider the traffic as http and respond accordingly, like an Nginx or Apache server. This bit is crucial in making the Trojan proxy so hard to distinguish. Our Trojan proxies are designed to serve various types of content via https requests. We do not get lazy and 301 redirect all requests to other websites and we actually put in the work and try to serve something of our own that would explain a bidirectional traffic flow - yes, bold on purpose.
I keep seeing examples from people using pictures or a CDN as a "dumb traffic" to fool the censors but that kind of exchange of data usually flows in just one direction: from the server to the client. Since the majority of your traffic will go through the Trojan proxy, the underlying http server should display something that explains this unusual amount of data that goes both ways (upload / download).
A Trojan client connects to a server just like a browser would do to a https endpoint. It performs a TLS handshake with a given domain name and, once authenticated, it sends SOCKS like commands. The traffic appears to a third party as a communication between you and a website.
There are various clients out there but we recommend V2BOX for a GUI experience or the official trojan-gfw for console. Basically any Trojan client should work as we do not plan on drifting away from the standards.
We highly recommend adding rules and only proxying the traffic that you really need to while allowing for some other traffic to flow at the same time, outside your tunnel with the proxy. This way you increase the chances of success since it makes it harder to identify it by mixing http requests in a healthy way so we highly recommend picking a client that has rules. Open a Wireshark instance or a network monitoring tool and try to pick as many requests that are done by your operating system or browser and allow them with the rules.
We recommend using a Trojan proxy only in cases where you want to bypass censorship and/or defeat firewalls. As examples I would use the firewalls from China or Iran, maybe censorship at work or school where traffic is restricted to regular http(s). For any other use case we recommend a SOCKS Proxy instead since it is more widely adopted among browsers and various other tools.
In terms of speed, it should be slower than a HTTP Proxy or SOCKS Proxy mainly due to the initial TLS handshake but we're talking nanoseconds here. Once the handshake/authentication part is done, the connection speed will match completely a SOCKS proxy.
As a big weakness I would add the fact that it still seems to be easily detectable. How? Well, all initial 56 bytes to every new connection will look the same. I do not know if firewall maintainers out there added checks in place specifically for this protocol yet but, should it gain popularity, I am quite confident it will be easily identified and blocked.
The overall idea and structure is very good so we are probably roll our own implementation that addresses these issues by rotating key encryptions. Stay tuned!
We offer highly secure, (Dedicated or Shared / Residential or Non-Residential) SOCKS5, Shadowsocks, DNS or HTTP Proxies.
DR SOFT S.R.L, Strada Lotrului, Comuna Branesti, Judet Ilfov, Romania
@2024 anonymous-proxies.net
