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

In the realm of global messaging, WeChat is a titan, boasting over 1.2 billion monthly active users. While most of the internet has converged on the Transport Layer Security (TLS) standard to protect user data, Tencent—the company behind WeChat—has taken a different path. For the past eight years, WeChat has relied on a proprietary protocol known as MMTLS. Until recently, this protocol remained largely a black box to the security community. Researchers from Citizen Lab recently pulled back the curtain, revealing a complex, double-layered encryption system that, while functional, suffers from significant cryptographic technical debt.

The Architecture of a Proprietary Protocol

WeChat's network communication is built on an infrastructure called MARS. This cross-platform component handles connection management, but the core encryption logic remains closed-source. By reverse-engineering the native libraries associated with MARS, researchers identified two distinct layers of encryption applied to every API request (or 'scene').

1. The Business Layer (Inner): This is the first layer of encryption applied to the Protobuf-encoded request data. It handles the specific application logic and differs based on the user's authentication state.
2. The MMTLS Layer (Outer): This layer wraps the encrypted business data. It is a custom fork of the TLS 1.3 draft, designed to handle the high-latency and often unstable network conditions common in mobile environments.

Technical Deep Dive: MMTLS and Its Discontents

The MMTLS Layer

MMTLS shares many primitives with TLS 1.3, including the use of AES-GCM for authenticated encryption. However, its most significant departure is its reliance on session resumption. To minimize the number of round trips required for a handshake—a critical performance metric for mobile apps—WeChat uses session resumption for almost all 'short-link' HTTP connections.

While this improves speed, it introduces a critical security trade-off: a lack of forward secrecy. In standard TLS, forward secrecy ensures that even if a server's long-term private key is compromised, past communications remain secure. By reusing keys through session resumption tickets for extended periods, MMTLS limits this protection. Furthermore, these resumed connections are technically susceptible to replay attacks, a known weakness in the resumption mechanism that standard TLS 1.3 works hard to mitigate.

The Flaws in Business-Layer Encryption

The inner 'Business' layer is where the most concerning cryptographic issues reside. When a user is logged out, the app uses Static Diffie-Hellman. Because the server's public key is hardcoded in the app and the server does not generate a new key pair for each session, the lack of forward secrecy is even more pronounced here than in the MMTLS layer.

Once a user logs in, the protocol shifts to a symmetric encryption mode using AES-CBC. The researchers found several alarming issues in this implementation:

• Forgeable Integrity Checks: The 'signature' used to verify data integrity was found to only check the length of the data, not the content itself. This allows an attacker (who can bypass the outer MMTLS layer) to modify the ciphertext without triggering an integrity error.
• Key/IV Reuse: The protocol frequently reuses Initial Vectors (IVs) with the same key, a classic cryptographic blunder that can lead to the decryption of traffic.
• Metadata Leakage: In older versions (pre-2016), this was the only layer of encryption, and it leaked significant metadata, including User IDs and request URIs. Even today, these identifiers are visible if the outer layer is stripped away.

Why Custom Crypto?

One might wonder why a company with the resources of Tencent would choose to 'roll its own crypto' rather than using standard, battle-tested libraries. The researchers suggest several possibilities. During the early 2010s, there was a general distrust of Western-led Certificate Authority (CA) systems in China. Additionally, Chinese ISPs are known for aggressive traffic filtering and poisoning; a custom protocol allows Tencent to fine-tune their traffic to avoid being inadvertently blocked or throttled by network middleboxes.

However, the most likely reason is technical debt. Having built a custom system early on, it became increasingly difficult to migrate the entire backend infrastructure to standard TLS without breaking backward compatibility for hundreds of millions of users.

Mitigation and Defense

For the end-user, there is little that can be done to 'fix' WeChat's encryption, as it is baked into the application. However, this research serves as a stark reminder for developers and security analysts:

• Prefer Standards: Always use standard, peer-reviewed protocols like TLS 1.3. The complexities of cryptographic implementation are so high that even massive companies like Tencent struggle to get custom implementations right.
• Forward Secrecy is Non-Negotiable: Modern applications must prioritize forward secrecy to protect user data against future compromises of server infrastructure.
• Audit Third-Party SDKs: Many international apps use Chinese SDKs that may inherit these proprietary, potentially broken encryption schemes.

Conclusion

The analysis of MMTLS reveals that while it is not 'trivially' broken like some other proprietary protocols found in the Chinese app ecosystem, it is significantly weaker than the global TLS standard. As we move toward an increasingly interconnected world, the reliance on 'black box' encryption remains a significant privacy risk. Transparency and adherence to open standards are the only ways to ensure that 'secure' messaging truly lives up to its name.