MTProto proxies are a specialized beast. Unlike HTTP or SOCKS5 proxies, they're built specifically for Telegram's protocol. Their primary purpose, particularly in regions with heavy internet censorship, is not just to route traffic but to make that traffic indistinguishable from ordinary HTTPS.
This is not a high-level overview. We're going to look at exactly how the protocol's obfuscation layer works, how FakeTLS leverages real certificate structures, and why Deep Packet Inspection (DPI) equipment—even with modern heuristics—struggles to block it.
The Two-Layer Architecture
Every connection through an MTProto proxy involves two distinct layers. The first is the transport layer (running on a TCP port, typically 443). The second is the MTProto payload inside it.
+-----------------------------------------------------------------+
| TCP Connection (Port 443) |
+-----------------------------------------------------------------+
| Obfuscation Layer (FakeTLS / Random Padding / Nonce) |
+------+----------------------------------------------------------+
| MTProto Payload (Encrypted Message, Session Key, Seq No) |
+------+----------------------------------------------------------+
The critical insight: DPI systems do not see Telegram packets unless they trigger a pattern match. The obfuscation layer is designed to ensure no pattern exists.
How the Obfuscation Handshake Works
When a client connects to an MTProto proxy, the proxy (or client) sends an initial obfuscation nonce. This is a random 64-byte payload that serves two purposes: it encrypts the inner protocol header using a derived AES key, and it validates the connection. The official Telegram documentation calls this "the obfuscation v2" handshake.
The inner header after decryption looks like this:
0xef (magic byte for obfuscated TCP)
random padding (up to the remaining MTU minus the nonce size)
crc32 checksum (4 bytes)
This random padding is the first major issue for DPI. The socket reads [nonce_size + random_padding] bytes before the actual protocol data. If the packet stream contains a session resume or a PING, the proxy shuffles bytes inside the envelope.
Where FakeTLS Comes In
FakeTLS is an optional but critical extension found in many MTProto proxy implementations—including those from the free-mtproto-proxies scraper. Instead of sending a raw obfuscated block, the proxy constructs a legitimate-looking TLS ClientHello message. This isn't a mock—it's a structure that matches real clients.
A standard TLS 1.3 ClientHello packet contains:
Handshake Type: 01 (ClientHello)
Length: variable
Version: 0x0303 (TLS 1.2) -> downgrade trick used to match median client fingerprint
Random: 32 bytes (structurally correct)
Cipher Suites: 2-4 modern suites, omitting weak DH ciphers
Extensions: SNI, Supported Groups (x25519), Key Share
The proxy replaces Random bytes with its obfuscation nonce. The cipher suite list, the SNI name (www.microsoft.com, usually), and the allowed extension list are hardcoded from real browser captures.
When DPI sees this, it parses it as a standard TLS handshake. The state machine in the DPI box transitions to "TLS session opened." Since the proxy responds with something that looks like a valid TLS continuation (but is also obfuscated), the DPI doesn't look deeper.
Why TLS Fingerprinting Fails Against Fractured Handshakes
Let's consider the DPI software approach. Systems like Nokia 7705 SAR or Qosmos' NBAR stack often use TLS fingerprints such as JA3 or Jabder. They compare the cipher suite ordering, extension order, and EC curve IDs to known malware or application profiles.
An MTProto proxy using FakeTLS from the common implementations sets parameters exactly like a typical curl or a Chrome 118 TLS handshake. The cipher suite order is the weaker trace: Chrome sends TLS_AES_128_GCM_SHA256 (0x1301) and a few elliptic curve suites. The proxy mirrors this. Every SSH- or HTTPS- disguised MTProto proxy must also ensure the server response timing (handling during SYN-ACK) matches real TCP delays, though some DPI firms now check round trip timing as a heuristic.
However, the critical layer of defense is injected random padding. After the encrypted inner packet, the proxy appends \x08\x08\x08\x08... or zeros to burn away the signature buffer.
[Nonce][Encrypted Payload][Random0x00 Pad up to 64 bytes]
This Random0x00 Pad makes a non-constant amount of padded bytes before and after each component. Even if the DPI reads enough bytes to extract the payload, it sees a disjointed TSDU that decoding logic discards because the frame size is technically smaller than the raw TCP buffer read. The DPI gets confused: it reads the buffer down to the TCP segment offset limit and hits random padding that states "segment unsized."
Putting It to Practical Use
On the client side, you don't need to manually implement the handshake. The MTPROTO protocol stack built into Telegram Desktop does it automatically once it resolves the proxy link format. A typical MTProto proxy link looks like:
tg://proxy?server=192.0.2.100&port=443&secret=ee...1243>some_secret
Modifying the secret hex string when connecting through FakeTLS adds extra obfuscated TLS extension parts to the outer packet. Implementation requires use of secret strings containing dd or ee leading bytes to toggle different encryption tiers.
One concrete tip: if you control the proxy server, run two instances. One on a high port (e.g., 3128) without FakeTLS for mobile usage where resources matter, and one on port 443 with FakeTLS for desktop. This ensures maximal compatibility without resorting to VPN layers.
The Repo and Practical Scanning
Maintaining a curated, up-to-date list of active MTProto proxies gets frustrating manually. IPs change daily, ports shift, and not all proxies support the crucial FakeTLS migration. That is exactly where the free-mtproto-proxies repository adds value. It runs a daily automated script that checks proxy availability, secret format correctness, and filters those with reliable connectivity. The published web listing displays the live secrets in ready-to-copy tg:// links, targeted specifically at users in restricted regions. If you run or maintain such an environment—or just want to inspect a source of working proxies to understand how the DPI-Testing ecosystem evolves—it's worth exploring as a practical resource rather than a static list of dead IPs.
Ultimately, MTProto proxies with obfuscation and randomized padding remain more resilient than typical transparent proxies due to this carefully designed misdirection at the transport layer. DPI no longer sees protocol markers; it sees noise occasionally wrapped in near-perfect TLS façades. Understanding this 'mathematical camouflage' gives developers far more reliable control over transmission circumvention, regardless of upstream filter policy changes.
Top comments (0)