How Baidu’s bdtls Protocol Secures Mini‑Programs with TLS 1.3‑Inspired Design

With the rapid growth of mobile apps, security risks such as static reverse‑engineering attacks, dynamic runtime attacks, and large‑scale business cheating have become critical concerns. Baidu’s mini‑programs run on multiple host apps, so a unified, end‑to‑end protected communication channel is required to prevent malicious interception and abuse.

Design Goals

Security: mutual authentication and full payload encryption with forward secrecy.

Low latency: encryption overhead less than 10 % of total request time.

Availability: hierarchical downgrade and fast recovery mechanisms.

Extensibility: support for multi‑business, multi‑app authentication and future cipher‑suite upgrades.

Why TLS 1.3?

TLS 1.2 suffers from a 2‑RTT handshake, outdated ciphers (RC4, DES, CBC, MD5, SHA‑1, etc.) and lacks built‑in support for the performance and flexibility required by Baidu’s ecosystem. TLS 1.3 reduces handshake to 1‑RTT, removes insecure algorithms, and introduces modern key‑exchange and AEAD ciphers, making it a perfect baseline for the new protocol, named bdtls .

bdtls Architecture

bdtls follows the TLS 1.3 layer model but operates between the application and transport layers, leaving the underlying network protocol unchanged. It defines four sub‑protocols:

Record : basic unit for sending/receiving encrypted records.

Handshake : negotiates version, random values, cipher suite, and performs mutual authentication.

Application : encrypts/decrypts business data on top of Record.

Alert : notifies the peer of warnings or fatal errors.

Handshake Protocol (3.2.1)

The handshake establishes a shared secret using Diffie‑Hellman Ephemeral (DHE) and authenticates the exchange with RSA signatures. The process includes:

Server generates an RSA key pair and sends the public key to the client.

Client creates a DHE private/public key pair, encrypts its public key with the server’s RSA public key, and sends it to the server.

Server decrypts the client’s DHE public key, generates its own DHE key pair, and sends the encrypted public key back.

Both sides compute the shared secret (master_secret) from the opposite DHE private key and received public key.

Server signs the hash of its encrypted DHE public key with its RSA private key; the client verifies the signature with the server’s RSA public key.

If verification succeeds, both parties derive the session key; otherwise the handshake aborts.

The DH key‑exchange steps are illustrated below:

RSA Signature

After establishing the DHE shared secret, the server signs the hash of its encrypted DHE public key using RSA. The client verifies this signature to prevent man‑in‑the‑middle attacks.

Alert Protocol (3.2.3)

Alerts are used to signal warning or fatal conditions during both handshake and business phases. Typical alerts include session‑trust failures (requiring a new handshake) and identity‑trust failures (terminating the connection).

Application Protocol (3.2.4)

Business data is encrypted with AES‑128‑GCM and authenticated with SHA‑256. The encrypted payload is sent as the HTTP/HTTPS body, making the entire transmission opaque to third parties.

Server Implementation (4.1)

Handshake Service : verifies host identity, validates package signatures, and checks business‑side authorization.

Encryption Service : decrypts the server‑side encrypted secret key (skr), validates its expiration, and performs AES‑GCM encryption/decryption of business payloads.

Host identity is enforced by issuing distinct key pairs per host and embedding a host identifier in the encrypted skr. Package signature verification ensures that only officially signed app packages can complete the handshake.

Client Implementation (4.2)

The client supports two integration modes:

Unified gateway: the mini‑program uses Baidu’s built‑in handshake service, requiring no server‑side deployment.

Business‑gateway SDK: external services integrate the bdtls SDK to handle their own handshake and encryption.

Strategy 1 – Multi‑handshake Merging

To avoid redundant handshakes when multiple concurrent requests need a key, each business task gets a dedicated handshake channel with its own thread and a sentinel that monitors handshake state. Pending requests are queued until the handshake completes, then dispatched.

Strategy 2 – Key Caching

After a successful handshake, the client persists the secret key, skr, expiration time, and DH group ID. On cold start, the cached object is restored, allowing immediate encrypted requests without a new handshake, provided the key is still valid.

Best Practices & Deployment Scope

bdtls is now used across Baidu’s open‑source host apps (e.g., iQIYI, Xiaohongshu), core mini‑program services (package management, authorization, request API), and internal Baidu services such as payment aggregation and video transcoding. It has passed the national “HVV” security exercise, confirming its robustness.

Limitations & Future Work

Currently bdtls implements a 1‑RTT handshake only; the 0‑RTT feature of TLS 1.3 is omitted to avoid ticket‑key leakage risks. The key‑exchange algorithm is DHE‑RSA; an upgrade to the more efficient ECDHE‑ECDSA suite is planned.

Overall, bdtls adapts TLS 1.3’s security guarantees to the application‑layer needs of Baidu’s mini‑program ecosystem, delivering lightweight, high‑performance, and highly available encrypted communication.