How We Built mmtls: A High‑Performance, Low‑Latency Secure Protocol for WeChat

mmtls Protocol Overview

Background

Frequent network‑security incidents have raised user awareness of communication safety. Major services such as Taobao and Baidu have deployed site‑wide HTTPS, but WeChat's original protocol encrypts only the payload, leaving headers (user ID, business ID) in clear text and using outdated cryptographic algorithms.

Objectives

Security : protection against eavesdropping, tampering, replay, and forgery.

Low latency & low resource consumption : avoid noticeable delay and keep backend load acceptable.

Availability : allow controlled degradation under extreme load without enabling downgrade attacks.

Extensibility : support future cryptographic upgrades and deprecate obsolete components.

Design Overview

mmtls sits between the application layer and WeChat's existing transport (long‑connection private protocol and short‑connection HTTP). It consists of three sub‑protocols analogous to TLS: Record, Handshake, and Alert.

Handshake Protocol – Secure Key Negotiation

The handshake establishes a shared symmetric key while authenticating the exchange. mmtls supports three negotiation modes (chosen for WeChat’s performance‑security trade‑off): 1‑RTT ECDHE, 1‑RTT PSK, and 0‑RTT PSK.

Key naming conventions used in the description:

pre_master_key, pre_shared_key, cli_pub_key, cli_pri_key, sign_key, verify_key, xxx_key

1‑RTT ECDHE

Alice and Bob generate ECDH key pairs ( ECDH_pub_key, ECDH_pri_key) and exchange public keys. The shared secret is derived with ECDH_compute_key. To prevent man‑in‑the‑middle attacks, each side signs its public key using ECDSA ( sign_key / verify_key).

0‑RTT PSK

When a PSK (issued in a previous successful ECDH handshake) is available, the client encrypts the first application data with the PSK‑derived key and sends it together with the handshake ticket ( ticket{key}). The server decrypts the ticket using its private ticket_key, obtains the symmetric key, and authenticates the payload.

Improving 0‑RTT Forward Secrecy

To mitigate the risk of long‑term key compromise, mmtls combines 0‑RTT PSK with an additional ECDHE exchange (0‑RTT ECDH‑ECDHE). The first data packet is protected by the static secret, while subsequent packets use an ephemeral secret, preserving forward secrecy even if the static key leaks.

Record Protocol – Authenticated Encryption

After the handshake, both parties possess a pre_master_key. mmtls expands this key with HKDF to derive separate write keys and IVs for client and server. AES‑GCM is used as an AEAD cipher, providing both confidentiality and integrity (Encrypt‑then‑MAC). The derived keys are:

<code>client_write_key, server_write_key, client_write_IV, server_write_IV</code>

Sequence numbers are incorporated into the AES‑GCM nonce to prevent replay attacks. For 0‑RTT connections, a global server‑side state and client‑side timestamps are used to limit replay windows.

Key Advantages

Lightweight: removes client authentication, embeds the verification key, and eliminates certificate exchange.

Strong security: uses TLS 1.3‑recommended primitives (ECDHE, ECDSA, AES‑GCM, HKDF‑SHA256) and adds 0‑RTT replay protection.

High performance: 0‑RTT handshake eliminates extra RTTs for short connections; optimized key‑expansion reduces latency.

High availability: server overload protection enables degraded but still secure service.

References

TLS protocol analysis and modern crypto protocol design

RFC 5246

The Transport Layer Security (TLS) Protocol Version 1.3