Technical

How "Fake TLS" Obfuscation Works (and Why It Helps)

A deep dive into the "ee" obfuscation variant that makes MTProto traffic look exactly like normal HTTPS.

MTProto Proxy Engineers · Censorship Circumvention Researchers

Published April 27, 2026 Updated May 15, 2026 8 min read 435 words

The TLS handshake in 60 seconds

When your browser connects to https://example.com, the very first packet sent is a TLS ClientHello. It contains the protocol version, supported cipher suites, the SNI (Server Name Indication, e.g. "example.com"), and a random 32-byte client nonce. Any DPI system can recognise this packet — it is the most identifiable shape on the entire internet. "Fake TLS" makes MTProto look exactly like one of these ClientHellos.

What "ee" actually does

When a proxy uses an "ee" secret, the very first packet of every connection is a real, valid-looking TLS 1.3 ClientHello. The SNI is set to a configurable hostname like "www.google.com" or "cdn.cloudflare.com". The cipher suite list matches what a modern browser would send. To a DPI inspector, the connection is indistinguishable from a real HTTPS connection to that hostname. After the handshake, the actual MTProto data flows inside what looks like the encrypted TLS body.

Get a free TGFast proxy

Browse the live country grid on the home page and tap any card to connect Telegram in one second — no signup, no logs.

Open the fleet

Why this helps in Iran and China

Iranian and Chinese DPI systems primarily target connections that "do not look like HTTPS" — i.e. high-entropy traffic on port 443 without a recognisable TLS handshake. With "ee" obfuscation, the connection passes the TLS handshake check. The DPI then allows it through (or at most flags it for slower deeper inspection, which the obfuscation also defeats).

How it cannot be blocked without breaking the internet

A DPI system that wanted to block "ee" MTProto would need to either: (a) selectively block connections to specific SNI hostnames, which would break access to the impersonated site itself; (b) verify TLS handshakes by completing them, which requires per-flow active probing and is expensive at scale. Most DPI systems do neither, which is why "ee" has had a long survival window.

Stay updated

Join @FastTGProxyMT for instant alerts when servers move or new proxies launch.

Join Telegram Channel

When to request an "ee" secret from TGFast

Default TGFast secrets are "dd" because they perform slightly better and are sufficient in most regions. Request "ee" by emailing support@tgfast.top if you are: in Iran (consistently), in China, or in any country that you observe blocking high-entropy port-443 traffic specifically. We can issue an "ee" secret within 24 hours.

Limitations

"ee" is not magic. Sufficiently sophisticated DPI can still distinguish MTProto from real TLS by analysing post-handshake traffic patterns (TLS sessions typically have characteristic packet sizes for HTML/CSS/JS; MTProto sessions look more like a streaming media flow). But this kind of analysis requires substantial compute and is not yet deployed at scale by any national censor.

Future evolution

The next generation of obfuscation, known as "uTLS" in the V2Ray ecosystem, dynamically randomises the entire TLS fingerprint per connection. This makes blocking even harder. We are evaluating uTLS for TGFast in 2026.

Frequently Asked Questions

How is MTProto different from SOCKS5 or Shadowsocks?

MTProto is Telegram's native protocol, so traffic looks indistinguishable from a normal Telegram connection to deep packet inspection. SOCKS5 is a generic proxy with a recognizable handshake; Shadowsocks adds obfuscation but still requires the operator to defend their port and keys against probing. MTProto with Fake-TLS adds a TLS-1.3-mimicking handshake that has proven the hardest of the three to fingerprint.

Why does the secret start with "dd" or "ee"?

The leading byte is a magic prefix that tells the Telegram client which obfuscation mode to negotiate. "dd" enables MTProto 2.0 random padding to defeat traffic analysis; "ee" indicates Fake-TLS mode where the entire session is wrapped in a TLS 1.3 handshake. Both are interoperable with all modern Telegram clients.

Can a network operator detect that I am using an MTProto proxy?

A determined operator can sometimes flag suspicious flows by timing analysis, but the encrypted payload itself is opaque. Fake-TLS makes detection significantly harder because the handshake mimics a real HTTPS site (including SNI, ALPN and certificate exchange). Even when flagged, blocking is per-IP, not per-protocol — which is why TGFast rotates IPs continuously.

Does an MTProto proxy add real cryptography or only obfuscation?

Both. The MTProto 2.0 transport adds AES-256-IGE encryption between client and server with per-session keys derived from the shared secret, and Fake-TLS wraps that channel inside a real TLS 1.3 handshake. Even if the proxy operator were malicious, they could not decrypt the inner Telegram session — that key is negotiated end-to-end with Telegram's data centres.

How does TGFast pick which servers to deploy and where?

We monitor latency and packet loss from probe nodes in 14 cities across the regions hit hardest by Telegram restrictions. New servers are spun up where the median latency to nearby ISPs falls below 80 ms and where the upstream provider has historically resisted ISP take-down requests. Capacity is rebalanced weekly.