FakeTLS Explained: How MTProto Becomes Invisible to Your Network.

What DPI sees without FakeTLS: the fingerprint problem.

Every network protocol has a fingerprint. Not in the payload — in the structure and timing of the opening exchange. TCP, HTTP, TLS, QUIC, WebSockets — each has a characteristic pattern of packet sizes, byte sequences, and timing intervals in the first milliseconds of a connection.

Deep Packet Inspection is the process of reading and classifying those fingerprints in real time, on every packet that passes through a network node. Modern DPI appliances can classify thousands of protocols and applications — Telegram, Netflix, BitTorrent, Zoom, Spotify — without reading the encrypted content. The fingerprint is in the shape of the traffic, not the words inside it.

MTProto 2.0 with Obfuscated2 randomises the opening bytes of the connection. The first packets look like noise — unidentifiable byte sequences rather than a recognisable protocol pattern. This defeats simple classifiers that match on specific byte patterns.

The problem is that "looks like noise" is its own signature. A connection that does not match any known protocol and begins with apparently random bytes is detectable as Obfuscated2, and some ISPs treat unidentifiable traffic as low-priority by policy — not because they know it is Telegram, but because it is not anything they prefer. Being invisible is not the same as being safe from throttling.

How FakeTLS forges the handshake.

FakeTLS constructs an opening exchange that passes DPI inspection as legitimate TLS 1.3. The key insight is that the DPI classifier is pattern-matching, not certificate-verifying. It checks whether the packet structure matches TLS. It does not validate whether the certificate is signed by a trusted CA or whether the SNI hostname resolves to the server's IP.

The FakeTLS implementation creates a ClientHello with the correct TLS record type, a plausible cipher suite list, standard TLS extensions, and a synthetic SNI hostname. The byte layout matches TLS 1.3 at the structural level. A classifier checking packet headers sees a TLS handshake initiation. It does not look further.

The proxy server on the receiving end knows to expect FakeTLS because of the 'ee' prefix in the secret. It unwraps the handshake layer, recovers the actual MTProto connection bytes, and forwards them to Telegram's data centre as standard MTProto. The masking is consumed and removed at the proxy — it exists only for the ISP-visible leg between your device and the proxy.

The forged handshake does not need to complete as a real TLS session because the DPI classifier has already passed the traffic before the session would need to be established. By the time any further validation could occur, the connection is already through the inspection point.

This is a structural property of how DPI operates — it classifies at the connection level, not at the session validation level. The FakeTLS technique exploits this gap deliberately and cleanly.

Obfuscated2 vs FakeTLS: what each does and why both exist.

These are two different layers addressing the same underlying problem — making MTProto less identifiable — using different approaches at different levels of the connection.

Obfuscated2 operates at the byte level of the MTProto framing. It randomises the initial handshake bytes of the MTProto connection itself, replacing the recognisable MTProto opening pattern with a random-looking sequence derived from the shared secret. It makes the MTProto connection look like nothing — unidentifiable bytes rather than a known protocol.

FakeTLS operates at the transport level, above Obfuscated2. It wraps the connection in a fake TLS handshake before the Obfuscated2 layer is even reached by the classifier. Instead of looking like nothing, the connection looks like HTTPS.

Both layers exist because different DPI systems pose different challenges. An Obfuscated2 connection that looks like "random bytes" might pass through a classifier that only throttles known Telegram fingerprints. But it would be flagged by a classifier that throttles any unidentified traffic. FakeTLS solves both: the connection has a positive identity (HTTPS) that no sane ISP will throttle.

The TradersProxy stack implements both layers. Obfuscated2 randomises the MTProto frame. FakeTLS masks the transport layer as TLS. The classifier faces a connection that looks like HTTPS from the outside and like noise at the protocol level if it somehow sees past the TLS presentation. Both layers are needed for robust DPI bypass.

Domain fronting: the next layer and its limits.

FakeTLS forges the structure of a TLS handshake. Domain fronting goes further — it routes the connection through a CDN or cloud provider whose hostname is the SNI in the ClientHello, then sends the actual request to a different backend. The connection appears to go to a major cloud provider (Cloudflare, AWS, Azure) rather than to a proxy server.

For MTProto use, domain fronting is a more complex and less reliable approach than FakeTLS for most traders. It requires the proxy to be reachable through a CDN that supports the technique, adds latency from the CDN hop, and is increasingly blocked by cloud providers themselves who do not want their infrastructure used this way.

FakeTLS achieves the essential goal — defeating ISP DPI classifiers — without the complexity and reliability costs of domain fronting. For the threat model relevant to signal delivery (ISP throttling of Telegram traffic), FakeTLS is sufficient. Domain fronting addresses a harder threat model: an ISP that actively blocks all traffic to known proxy server IPs, which is uncommon in the jurisdictions where most traders operate.

TradersProxy uses FakeTLS. Domain fronting is not implemented because it introduces CDN latency and reliability dependencies that would degrade the infrastructure for the primary use case. The added complexity solves a threat model most traders do not face.