Fake TLS in MTProxy: How Traffic is Masked as HTTPS
Early versions of MTProxy obfuscated traffic, but they had an Achilles' heel: DPI systems learned to find characteristic byte patterns in the handshake. Fake TLS is a mode in which a connection to the proxy is indistinguishable from opening a regular HTTPS website from the perspective of any observer. Let's break down the mechanism from the inside.
Why mask traffic as TLS
TLS (Transport Layer Security) is the protocol that secures all HTTPS websites. The browser padlock, bank transfers, email — all of these are TLS. Because of its ubiquity, an ISP cannot block all TLS traffic without shutting down the internet entirely.
The idea behind Fake TLS is simple: make the MTProxy connection indistinguishable from a regular TLS connection to a legitimate website. Then, the only way to block the proxy is to block the legitimate website itself (e.g., google.com), which is politically impossible.
Structure of the Fake TLS secret key
The proxy secret is the string you see when adding a proxy in Telegram. For the Fake TLS mode, it has the following structure:
ee367dbc7ce59d9a56e8f59b9cadef34676f6f676c652e636f6d
│ │ │
│ └── 32 hex chars of the key └── hex("google.com")
└── Fake TLS prefix
Three parts:
ee— a two-character marker for the Fake TLS mode- 32 hex characters — a 16-byte encryption key
- hex string — the UTF-8 representation of the SNI domain in hexadecimal format
The Telegram client automatically decodes this format and knows everything needed for the connection.
What the proxy handshake looks like
When you connect via Telegram, the following sequence unfolds:
The DPI only sees the traffic passing through it. Everything looks like normal HTTPS to google.com.
Why Client Hello is the key element
The Client Hello is the first message in the TLS handshake. It contains the SNI (Server Name Indication) field: plaintext with the domain name. This is the only place in the encrypted connection where the DPI can read the hostname without breaking the encryption.
Fake TLS uses this field strategically: it places the name of a major CDN domain there. Blocking traffic with the SNI cloudflare.com or google.com means blocking millions of legitimate services.
How to choose a domain for SNI
Not all domains protect your proxy equally:
| Criterion | What to look for |
|---|---|
| Traffic volume | Domains with millions of requests per second — blocking is too costly |
| CDN coverage | If a domain is behind a CDN (Cloudflare, Akamai), its IP cannot be blocked en masse |
| Reputation | Banks, major media — blocking is politically sensitive |
| Availability | The domain must work in the target country, otherwise the SNI check will fail |
Bad choices: obscure domains or domains already blocked in the country.
What the proxy does during active DPI probing
Advanced DPI systems do not just passively observe — they actively probe suspicious connections: they connect to the server themselves and check if it reacts like a real HTTPS server.
A proper MTProxy implementation handles this like so: upon receiving a suspicious request, the server proxies it to the real HTTPS server of the decoy domain. To the DPI, everything looks like a legitimate connection to google.com.
Limitations of Fake TLS
ECH (Encrypted Client Hello) is a new standard that fully encrypts the SNI. When ECH is widely adopted by ISPs, DPI will not be able to read the domain name at all. But until it is deployed en masse, Fake TLS remains relevant.
Statistical flow analysis — with prolonged observation, systems might notice differences from "real" TLS: atypical timings, certificate structure. This requires expensive computations.
IP blocking — Fake TLS protects against signature-based filtering, but not against blocking the proxy's IP address. This is exactly why MTProxyHub rotates nodes every 60 seconds.
Similar approaches in other tools
Fake TLS is not unique to Telegram — it is part of a broader censorship circumvention ecosystem:
- Shadowsocks with obfs4 and v2ray-plugin
- V2Ray/Xray in WebSocket + TLS mode
- Tor with meek and snowflake bridges (uses real domain fronting via CDN)
They are united by a single idea: hiding in the shadow of legitimate HTTPS traffic.
FAQ
How to distinguish a Fake TLS proxy from a regular one?
A Fake TLS secret always starts with ee. Older proxies started with dd or came without a prefix.
Can I find out the SNI domain from the secret?
Yes — it is encoded at the end of the string as hex UTF-8. For example, 676f6f676c652e636f6d = google.com.
What happens if the DPI sends a probing request? A proper MTProxy server will redirect it to the real HTTPS host of the decoy domain.
Why not real TLS? Real TLS would require certificates and PKI, making the proxy identifiable via Certificate Transparency.
If you just need a working connection right now, open the list of nodes with Fake TLS. All proxies support ee secrets by default.
Also read: how DPI works and how to set up your own MTProxy server.