MMTLS

定义

MMTLS是位于业务层与网络连接层之间的一层安全传输协议，其作用类似HTTP与TLS组合成HTTPS的关系：业务数据交给MMTLS封装后，由它负责保密性与完整性，再经由微信的长连接或短连接发出^[1]。按微信终端开发团队的说明，协议内部同样划分为Record协议、Handshake协议与Alert协议三个子协议，其中Handshake负责握手协商出对称密钥，Record负责用该密钥加密业务数据，Alert用于通知对端出错并要求关闭连接。

在微信的通信结构中，MMTLS不改变原有的网络策略，只是包裹在其外层：短连接仍是HTTP承载，长连接仍走微信私有协议，二者都建立在TCP之上^[2]。这套协议不随腾讯Mars开源组件一同发布，是微信客户端专有的实现^[3]。

原理

MMTLS沿用"认证密钥协商+对称加密传输"的混合结构。握手阶段通过ECDH交换公钥，双方各自用本地私钥与对方公钥算出同一份共享密钥；为防止中间人替换公钥，服务端会用长期保存的sign_key对临时公钥签名，客户端以内置的verify_key验签后才继续协商。与TLS不同，MMTLS只对服务端做认证，不对客户端做认证，理由是客户端程序发布后人人可得，其完整性不属于协议保护范围^[1]。

在公钥分发方式上，MMTLS没有采用证书链，而是把verify_key直接内置进客户端，从而省去证书链传输的带宽开销与验签耗时；一旦sign_key存在泄露风险，则通过强制升级客户端来更换内置公钥，替代TLS中CRL与OCSP的撤销机制^[4]。协商出的pre_master_secret并不直接作为会话密钥，而是经HKDF扩展为加密密钥与初始化向量；微信团队对TLS 1.3草案中3次HKDF-Extract加4次HKDF-Expand的流程做了精简，以降低PSK握手时的性能开销^[5]。

握手方式上，MMTLS只保留了1-RTT ECDHE、1-RTT PSK与0-RTT PSK三种。长连接建立时会先发探测包，1-RTT握手可借这个包完成，不增加时延；短连接原本只有一个往返，因此优先采用0-RTT PSK，客户端直接用先前下发的预共享密钥加密首个业务包^[6]。数据加密选用AES-GCM这一AEAD类算法，把加密与完整性校验合并在同一算法内部，避免AES-CBC只提供保密性而不保证完整性的问题。

加密数据包的结构可简示为：Record = 加密后的业务数据 ‖ GCM 认证标签，密钥由 $K = \mathrm{HKDF\text{-}Expand}(PRK,\ \mathrm{info},\ L)$ 派生，其中info由输出长度、用途标签和握手消息哈希拼成，以保证同一连接内派生的密钥唯一^[1]。

发展历程

MMTLS出现之前，微信采用的是业务层加密：只加密请求包的包体，包头中的用户标识与业务请求标识仍为明文，以便代理服务器做路由，这使被截获的数据存在被关联分析的风险；同时其密码学算法与业界最新成果存在差距^[1]。公民实验室的研究也指出，在MMTLS之前业务层加密是微信网络请求唯一的加密层，旧版本中该层的AES-CBC实现还曾暴露于填充预言类攻击^[3]。

2016年前后，微信开始启用MMTLS作为外层加密^[7]。微信团队说明，当时TLS 1.3仍是草案、缺少可用的标准实现，而通用协议对微信自身特点的优化空间有限，因此选择以TLS 1.3草案为基础自行设计协议^[1]。2018年1月，微信终端开发团队公开刊出《基于TLS1.3的微信安全通信协议mmtls介绍》，系统披露了该协议的架构与设计取舍。

同年的IEEE IPCCC会议上，有研究者发表了对MMTLS加密流量进行分类的论文，指出微信绝大部分通信由这一专有协议承载，其设计基于TLS 1.3草案，并认为MMTLS适合低时延、轻量消息的场景^[8]。2024年10月，多伦多大学公民实验室(Citizen Lab)发布对微信网络加密的首份公开安全分析，指出MMTLS之外还存在与其独立的业务层加密，两者像套娃一样嵌套使用^[9]。

应用

MMTLS最主要的用途是承载微信客户端的网络请求。研究者指出，微信的支付、广告点击、朋友圈浏览等七类典型用户活动均在MMTLS加密信道内完成，其流量与同时使用的HTTPS并存^[10]。在协议内部，长连接与短连接分别对应不同的握手组合：长连接使用1-RTT ECDHE或1-RTT PSK，短连接在持有PSK时使用0-RTT PSK^[2]。

这套协议的实现也被延伸到微信生态的其他接入场景。腾讯云推出的小程序安全加速方案即宣称采用微信私有协议，对包括接口在内的数据进行加密，并通过ECDH密钥协商与PSK机制提高分析门槛^[11]。

局限

MMTLS的首要局限在于它并非端到端加密。公民实验室指出，该协议保护的是用户设备与微信服务器之间的链路，服务器可以解密并读取每条传输的消息^[9]。与MMTLS并存的业务层加密还有元数据泄漏问题，用户账号标识与请求URI在这一层未被加密，若攻击者能在微信内网部署监听，仍可能针对被转发的请求发起攻击^[12]。

在密码学设计上，研究指出MMTLS每条连接只在开头生成一次确定性初始化向量(IV)，此后逐条递增，这与NIST不建议对AES-GCM的IV采用完全确定性派生的建议相左，因为(key, IV)一旦重复将危及密钥本身的安全^[13]。前向保密性也受到限制：由于0-RTT重协商被大量使用，短连接数据始终由预共享密钥保护，前向保密实际上只限于单次会话，密钥在用户关闭并重开应用时才轮换^[13]。此外，研究者认为MMTLS体系中重放攻击的可能性未被完全排除，微信自身的技术文章也承认防重放需要业务层配合^[13]。

这些局限更多属于设计取向而非可直接利用的漏洞。公民实验室表示未在MMTLS中发现严重安全问题，也未找到足以破解微信网络加密的方法，并建议腾讯改用标准TLS或TLS与QUIC的组合。该研究同时提示，由于获取中国手机号存在限制，其测试使用的是非中国号码，应用行为可能与国内版本存在差异^[3]。

参见

• TLS —— MMTLS以TLS 1.3草案为蓝本设计，二者在握手、记录层与密钥派生上结构相近。

• ECDH —— MMTLS握手阶段用于协商共享密钥的椭圆曲线密钥交换方法。

• AES-GCM —— MMTLS采用的AEAD类对称加密算法，同时提供保密性与完整性。

• HKDF —— MMTLS用来把握手结果扩展为会话密钥的密钥派生函数。

• 微信 —— 采用MMTLS作为主要网络加密协议的即时通讯应用。

• 前向保密 —— 评估MMTLS安全强度的关键指标之一。