Should We Chat, Too? Security Analysis of WeChat's MMTLS Encryption Protocol

Should We Chat, Too? Security Analysis of WeChat's MMTLS Encryption Protocol

Speakers: Pelleon, Researcher, Citizen Lab at University of Toronto; Mona, PhD Student, Princeton University, Center for IT Policy

Conference: Black Hat Asia

YouTube: https://www.youtube.com/watch?v=i98Ce4NhjhA

Overview

This talk, delivered by Pelleon from the Citizen Lab at the University of Toronto and Mona, a PhD student at Princeton University and former Citizen Lab research fellow, delves into a comprehensive security analysis of WeChat's proprietary encryption protocol, MMTLS. WeChat, a ubiquitous mobile application with billions of users, employs a custom, multi-layered encryption scheme instead of widely adopted and scrutinized open standards like TLS/SSL. The speakers meticulously reverse-engineered this custom protocol, revealing its intricate architecture, cryptographic primitives, and significant security weaknesses. The core motivation for this research stemmed from the observation that WeChat's network traffic was heavily obfuscated, prompting an investigation into "what's being sent" and the soundness of its encryption.

The significance of this research cannot be overstated. While TLS secures approximately 80% of internet traffic and benefits from over 30 years of development, open standards, and extensive public scrutiny, WeChat's MMTLS operates largely in obscurity. Despite being deployed for around eight years and securing traffic for billions, public documentation on MMTLS has been limited to a single, incomplete blog post from Tencent. This lack of transparency and independent review raises critical questions about the protocol's robustness against various adversaries, including sophisticated state-sponsored actors and common man-in-the-middle (MITM) attackers. The findings highlight the inherent risks of relying on "security through obscurity" and proprietary cryptographic implementations, advocating for a universal adoption of open, well-vetted encryption standards.

Background

▶ Watch: Introduction, agenda, and motivation for WeChat analysis (0:00)

The Citizen Lab's extensive research into mobile app security and privacy naturally led them to target WeChat, given its immense global user base. Initial attempts to analyze WeChat's network traffic revealed it to be standard HTTP, but with all internal data heavily obfuscated, indicating the presence of custom encryption. This observation sparked the detailed investigation into what WeChat was transmitting and the underlying cryptographic mechanisms.

The problem WeChat presents is a microcosm of a broader issue prevalent in many applications, particularly those developed in regions with unique internet ecosystems. Despite the widespread adoption and robust security guarantees of TLS 1.3, WeChat, like many other applications, opted to develop and deploy its own proprietary encryption protocol, MMTLS. This decision is particularly perplexing given the maturity, public scrutiny, and continuous improvement of TLS over decades. MMTLS has been in use for approximately eight years, yet its inner workings have remained largely opaque, with only a partial public blog post from Tencent offering any insight. This stands in stark contrast to the open development and peer review that underpins the security of TLS.

The speakers also touched upon Tencent's own acknowledgment of prior security deficiencies. Before 2016, WeChat's "business layer" encryption was the sole cryptographic protection, which, as the research later confirmed, suffered from significant flaws, including metadata leakage and poor cryptographic guarantees. The introduction of MMTLS in 2016 was ostensibly a response to these issues, but rather than replacing the problematic layer, Tencent opted to layer MMTLS on top, creating a complex, two-tiered encryption "lasagna" that inherited some of the weaknesses of its predecessor. The talk speculates on several reasons why Chinese apps, including WeChat, might prefer custom cryptography over TLS, ranging from historical distrust in Western-dominated TLS certificate authority ecosystems, a desire to obfuscate traffic, performance and compatibility concerns within China's unique internet environment (including ISP filtering and traffic poisoning), to the "not invented here" syndrome and simple technical inertia.

Key Findings

▶ Watch: Overview of WeChat's internal API request structure (4:00)

The core of the research uncovered a complex, two-layered encryption architecture within WeChat: the MMTLS layer and the business layer encryption. Crucially, the business layer exhibits different cryptographic behaviors depending on whether a user is logged out or logged in.

At the MMTLS layer, the protocol is strikingly similar to TLS, employing familiar primitives such as records (handshake, data, alert), similar terminology, and even shared "magic numbers" for record types. It utilizes AES-GCM for encryption and authenticity. However, the analysis revealed several critical deviations from TLS 1.3, including a more limited cipher suite selection, pinned keys and certificates, and a heavy reliance on session resumption for short link connections. This heavy use of session resumption means that each resumed request lacks replay resistance, a known vulnerability in TLS session resumption when not properly mitigated. While Tencent has provided some public documentation on this layer, they themselves acknowledge flaws stemming from their modifications to TLS 1.3.

The business layer encryption, for which there is no public documentation, presented even more severe issues:

• Logged Out State: This layer uses static Diffie-Hellman with AES-GCM. A significant finding here is the lack of forward secrecy for data sent by the client. The server's public key is static and pinned within the application. If this static server private key were ever compromised, all past client-sent session data could be decrypted retrospectively.
• Logging In State: During the login process, static Diffie-Hellman is used to retrieve and decrypt a specific encryption key from the server.
• Logged In State: Once logged in, the application uses this server-delivered fixed key with AES-CBC and a forgeable checksum. The checksum, instead of verifying the integrity of the data, only validates the length of the message. This renders the checksum cryptographically useless, providing no cryptographic guarantees for authenticity or integrity. This symmetric encryption scheme, using a fixed key and a forgeable checksum, represents a critical vulnerability. Prior to 2016, this was the only layer of encryption, meaning it leaked metadata like user IDs and request URIs, and was vulnerable to straightforward attacks.

Upon reporting these findings to Tencent, their response indicated an intention to upgrade the business layer encryption to use AES-GCM instead of AES-CBC, which would address the forgeable checksum issue. However, the speakers expressed confusion, questioning why Tencent would focus on fixing the inner layer rather than adopting full TLS. They hypothesized that the business layer might be the only layer used within WeChat's internal networks, making its weaknesses a potential target for internal surveillance, akin to the NSA's wiretapping of Google's internal networks exposed in the Snowden leaks.

Beyond WeChat, preliminary findings from ongoing research indicated a broader, worrying trend: many other popular applications, particularly those from Chinese developers, employ proprietary cryptography. The analysis of these other protocols revealed that "all of them except for MMTLS contained really bad vulnerabilities or were able to break the encryption," highlighting that WeChat's MMTLS, while flawed, was comparatively more robust than many other custom implementations.

Technical Deep Dive

▶ Watch: Deep dive into the first layer: Business Layer Encryption (6:10)

WeChat's network requests, internally referred to as "scenes," are fundamental to its operation. Each API call corresponds to a defined API endpoint with a unique type number and an internal URI, which is not visible in plain HTTP traffic. Request and response formats are defined using Protobuf. For example, user registration involves specific fields like email, mobile number, and username, associated with a request type number (e.g., 126) and a URI (e.g., /cgi-bin/micromsg-bin/something).

When a user interacts with the app, the UI logic triggers a "scene" API, calling a doScene method. The Java API serializes data fields into a byte array, which then enters the first layer of encryption: the business layer encryption. This layer is primarily implemented in Java, but delegates mathematical calculations to native libraries, which in turn call OpenSSL. The output is a business layer ciphertext.

This ciphertext is then passed to a C++ task manager called Net Core, which handles connection state and network queuing. Net Core initiates the second layer of encryption, the MMTLS encryption, generating the MMTLS ciphertext that is sent over outgoing connections. The entire process is reversed on the server side: MMTLS decryption, then business layer decryption, to retrieve the original plaintext, which is then handled by the application via an onSceneEnd callback.

A crucial underlying component is Mars, Tencent's cross-platform infrastructure component. Network requests are handled by the SDN module within Mars. Mars itself is partially open-source on GitHub ("Mars Open"), but also includes a "Mars Private" part (potentially open-source in the future) and a "Mars WeChat" part, which contains WeChat-specific code, including the proprietary MMTLS encryption. The open-source components were invaluable for reverse-engineering, providing symbols and C++ structures.

The encryption process is likened to a "pile of lasagna" due to its two distinct layers. WeChat employs two main transfer protocols:

• Long Link: Operates over TCP port 8080. These are long-lived connections supporting multiple request-response cycles, likely used for server-initiated transmissions like push notifications.
• Short Link: Operates over HTTP POST on port 80. These are short-lived connections, supporting only a single request-response cycle before closing. This is the most common type, used for client-initiated transmissions.

MMTLS Key Derivation:

• Long Link Connection: The client generates a new key pair for each connection and sends its public key to the server. The server then generates its own key pair and replies with its public key. Both parties then possess enough information to perform a Diffie-Hellman (DH) key exchange and derive a shared secret, which is used for encrypting and decrypting application data.
• Short Link Connection: Due to the single request-response nature of HTTP POST, a full DH handshake for every connection is impractical. Instead, all short link connections rely on session resumption. The very first short link connection (e.g., when the app is opened) performs a full DH handshake. The server responds with its public key and a resumption ticket. Subsequent short link connections use this resumption ticket, allowing the client to indicate a previously established public key, which the server remembers. This mechanism allows both sides to derive the shared secret without a full handshake in every request. However, as noted, this heavy reliance on session resumption leads to a lack of replay resistance.

MMTLS also differs from TLS 1.3 by having an extra record header for handshake resumption packets, though other record types (handshake, data, alert) share the same magic numbers as TLS, indicating a clear lineage or inspiration.

Business Layer Encryption (Internal/Pre-MMTLS Layer):

This layer's behavior changes based on user login status:

• Logged Out (Asymmetric Mode): Uses static Diffie-Hellman. The server's public key is hardcoded ("pinned") in the app. The client generates its private key and, using the static server public key, computes a session secret. For the response data, the server generates a new public key, which is sent in the response metadata, allowing the client to derive a separate secret for decryption. Encryption and authenticity here are handled by AES-GCM with a tag. A major flaw is the lack of forward secrecy: if the static server private key is compromised, all past client-sent data encrypted using it can be decrypted.
• Logging In: This phase uses static Diffie-Hellman to securely retrieve and decrypt an ephemeral session key from the server. This session key is then saved by the client.
• Logged In (Symmetric Mode): All subsequent requests, once logged in, are encrypted using this server-delivered session key with AES-CBC. Critically, this layer uses a forgeable checksum that only verifies the length of the data, not its content. This means the checksum offers no cryptographic guarantees of integrity or authenticity, making the data susceptible to manipulation without detection.

The speakers highlighted that the business layer encryption, particularly its symmetric mode when logged in, represents a significant vulnerability, especially given that it was the only layer of encryption prior to MMTLS's introduction in 2016.

Demo / Proof of Concept

▶ Watch: Introduction to the second layer: MMTLS Encryption (7:40)

The talk focused on the detailed security analysis and reverse-engineering of WeChat's MMTLS encryption protocol and its underlying business layer. The speakers presented their findings and cryptographic breakdowns based on static and dynamic analysis of the application's native libraries. There was no live demonstration or proof-of-concept exploit shown during the presentation. The research primarily involved dissecting the proprietary cryptographic implementations to identify their design and inherent weaknesses.

Defensive Implications

▶ Watch: Explanation of Tencent's cross-platform Mars library (9:00)

The findings from this analysis carry significant implications for both WeChat's developers and the broader cybersecurity community, particularly for defenders.

For WeChat/Tencent: The most straightforward and robust recommendation is to fully transition to a standard, well-vetted protocol like TLS 1.3. The current two-layered custom encryption, while not trivially broken in its MMTLS component, introduces unnecessary complexity and potential attack surfaces. The decision to "fix" the inner business layer by upgrading it to AES-GCM, while an improvement over AES-CBC with a forgeable checksum, still leaves a custom, undocumented layer beneath MMTLS. This layered approach complicates auditing, increases the likelihood of human error in implementation, and makes continuous security assessment challenging. The "lasagna" approach should be replaced by a single, robust, and openly scrutinized cryptographic stack.

For Defenders and Users:

• Awareness of Custom Encryption Risks: The primary takeaway is that custom encryption, particularly in widely used applications, poses significant risks. Unlike TLS, which benefits from open standards, extensive academic review, and community scrutiny, proprietary protocols like MMTLS can harbor undisclosed vulnerabilities that are exploitable by sophisticated adversaries (e.g., nation-states) or even less skilled MITM attackers. The forgeable checksum in WeChat's logged-in business layer is a prime example of a critical flaw that could allow for data manipulation.
• Lack of Forward Secrecy: The static Diffie-Hellman used in the logged-out business layer means that if WeChat's static server private key is ever compromised, all past communications encrypted with it could be decrypted. This is a severe weakness that standard TLS protocols are designed to mitigate through ephemeral key exchanges.
• Internal Network Vulnerabilities: The hypothesis that the business layer might be exclusively used for internal WeChat network communications is particularly concerning. If true, any vulnerabilities in this layer could be exploited by actors with access to WeChat's internal infrastructure, potentially enabling mass surveillance without external detection, reminiscent of the NSA's operations against Google's internal networks.
• Global Impact of Chinese Apps/SDKs: It's crucial to understand that the implications extend beyond Chinese users. WeChat has a substantial international user base. Furthermore, Chinese SDKs are often integrated into non-Chinese applications, potentially importing these same proprietary, vulnerable encryption schemes into apps used by a global audience. The report on Red Nunu, which contained severe MITM vulnerabilities, serves as a stark warning.
• "Front Door" Vulnerabilities: The speakers emphasized that many proprietary protocols found in other apps are not just subtly weak but "completely broken," effectively acting as "front doors" for anyone with basic cryptographic knowledge. This underscores the need for continuous, public security analysis.

Broader Recommendations for the Security Ecosystem:

• Continuous, Public Research: There is a strong call for ongoing, independent security and privacy studies of consumer applications, with results publicly released. Relying on private security firm reports that are sold commercially limits access to critical information for individual users and the broader research community.
• Engagement with Global South Developers: Researchers should actively engage with developers and engineers in the Global South, who may lack access to resources or training in best security practices. Fostering this engagement can help elevate the baseline of cryptographic security globally.
• App Store Attestation and Rigorous Reviews: App stores (like Xiaomi and Google Play) should implement more rigorous review processes for apps employing proprietary encryption. Furthermore, they should provide clear attestation information on app pages, informing users if an app uses custom encryption and highlighting potential security implications (e.g., "This app uses proprietary encryption, which may be insecure").
• OS Vendor Support: Operating System vendors should provide better documentation and easy-to-use development tools that guide application developers towards correctly implementing and utilizing secure, standard cryptographic practices.

These defensive implications underscore a fundamental principle: security through obscurity is not security. Open standards, peer review, and transparent implementation are paramount for building trustworthy digital infrastructure.

Key Takeaways

• Two-Layered Proprietary Encryption: WeChat utilizes a complex, two-layered custom encryption scheme, comprising an outer MMTLS layer and an inner business layer, instead of standard TLS.
• Critical Business Layer Flaws: The inner business layer, particularly when a user is logged in, suffers from severe cryptographic weaknesses, including the use of a server-delivered fixed key, AES-CBC, and a forgeable checksum that only validates message length, offering no integrity or authenticity guarantees. It also lacks forward secrecy when logged out.
• MMTLS Deviations from TLS: While MMTLS is inspired by TLS, its modifications, such as heavy reliance on session resumption for short links, introduce vulnerabilities like a lack of replay resistance.
• Partial Fixes, Not a Full Solution: Tencent's commitment to upgrade the business layer to AES-GCM is an improvement but does not address the fundamental risks associated with layering custom, undocumented cryptography over a TLS-like protocol.
• Widespread Problem Beyond WeChat: The use of proprietary and often deeply flawed encryption is a pervasive issue across many popular applications, especially those from the Global South, making users vulnerable to MITM attacks and surveillance.
• Call for Transparency and Standards: The research strongly advocates for continuous public scrutiny of consumer app security, greater engagement with developers in resource-constrained regions, and app store policies that promote the adoption of open, well-vetted cryptographic standards like TLS over custom, opaque implementations.

About the Speaker(s)

Pelleon is a researcher at the Citizen Lab, an interdisciplinary research organization at the University of Toronto. His primary research focus is on the security and privacy of mobile applications, particularly consumer-facing apps. In the past, Pelleon has conducted detailed studies on popular platforms such as TikTok and Douyin, and also analyzed several COVID-19 contact tracing apps in Southeast Asia during the pandemic.

Mona is a network security researcher and applied cryptographer, currently pursuing a PhD in Computer Science at Princeton University, affiliated with their Center for IT Policy. She previously served as a research fellow at the Citizen Lab, where she collaborated with Pelleon on this extensive analysis of WeChat's MMTLS protocol. Mona is deeply committed to privacy and security, having also worked as a technologist at the Electronic Frontier Foundation (EFF). Her broader research interests include network measurement, network censorship measurement, traffic fingerprinting, and threat modeling for labor organizers.