基于 TLS 1.3的微信安全通信协议 mmtls 介绍（上）

一、背景

随着近些年网络安全事情的频繁发生，使得用户对网络通信安全的意识越来越强。国内外的网络服务提供商都逐渐提供全站的安全通信服务，如国内的淘宝、百度先后宣布已经完成了全站部署 https。微信现有的安全通信协议是基于用户登录的时候派发的 SessionKey 对应用数据进行加密的，该协议在工程实现上，已经过多次迭代优化，但是仍然有一些缺点：

1、原有的加密通信协议是存在于业务层的。加密保护的是请求包包体部分，但是包头部分是明文，包头包含用户 id 和请求的业务 id 等信息，这主要是为了在 proxy 做路由所需要的。这样会存在数据被截获后建立映射关联分析的风险。　

2、原有的加密通信协议使用的密码学协议和算法与业界最新成果有差距，安全强度有待加强。　

鉴于上述原因，微信需要一套能够加密保护 Client 到 Server 之间所有网络通信数据、且加密通信保护必须对业务开发人员透明的安全通信协议，由此诞生了 mmtls。

二、目标

考虑到系统安全性与可用性和性能等指标之间可能存在相互影响，某种程度上，安全性与这些指标是负相关的。因此在设计的时候对 mmtls 提出了以下要求：　

1. 安全性。主要体现在防窃听，防篡改，防重放，防伪造。　
2. 低延迟、低资源消耗。要保证数据在传输过程中不会增加明显的延迟；后台负载增加在可接受范围。
3. 可用性。在一些极端情况下（如 server 负载过高），后台能够控制提供降级服务，但是要注意不能被攻击者利用，进行降级攻击。
4. 可扩展性。协议要可扩展、可升级，方便添加安全强度更高的密码学组件，方便禁止过时的密码学组件。

通过分析一些业界公开的安全通信协议发现，它们都不能完全满足我们的要求，例如 TLS1.2 中每次建立一个安全连接都需要额外的 2~1 个 RTT（全握手需要 2-RTT），对于微信这么一个需要频繁网络通信的 IM 软件来说，这对用户体验的伤害是极大的，尤其是在大量短连接存在的情况下，额外的 RTT 对用户延迟的影响是相当明显的。好在 TLS1.3 草案标准中提出了 0-RTT（不额外增加网络延时）建立安全连接的方法，另外 TLS 协议本身通过版本号、CipherSuite、Extension 机制提供了良好的可扩展性。但是，TLS1.3 草案标准仍然在制定过程中，基于标准的实现更是遥遥无期，并且 TLS1.3 是一个对所有软件制定的一个通用协议，如果结合微信自己的特点，还有很大的优化空间。因此我们最终选择基于 TLS1.3 草案标准，设计实现我们自己的安全通信协议 mmtls。

三、mmtls 协议设计

3.1 总体架构

[1500448368556_104_1500448369277.jpg]

业务层数据加上 mmtls 之后，由 mmtls 提供安全性，保护业务数据，这类似于 http 加上 tls 后，变成 https，由 tls 保护 http 数据。mmtls 处于业务层和原有的网络连接层之间，不影响原有的网络策略。对于微信来说这里的网络连接层就是微信长连接（私有协议）和微信短连接（http 协议），都是基于 TCP 的。

图 1 描述的是把 mmtls 看成一个整体，它所处的位置。进入 mmtls 内部，它包含三个子协议：Record 协议、Handshake 协议、Alert 协议。这其实是和 TLS 类似的。它们之间的关系如下图：

[1500448537515_8340_1500448538002.jpg]

Handshake 和 Alert 协议是 Record 协议的上层协议，业务层协议（Application Protocol）也是 record 协议的上层协议，在 Record 协议包中有一个字段，用来区分当前这个 Record 数据包的上层协议是 Handshake、Alert 还是业务协议数据包。Handshake 协议用于完成 Client 与 Server 的握手协商，协商出一个对称加密密钥 Key 以及其他密码材料，用于后续数据加密。Alert 协议用于通知对端发生错误，希望对端关闭连接，目前 mmtls 为了避免 server 存在过多 TCP Time-Wait 状态，Alert 消息只会 server 发送给 client，由 client 主动关闭连接。

说明：在下文中，会出现多个对称密钥和多个非对称密钥对，在本文中我会给有些密钥取一个专有的名字，以方便理解避免混淆，如:pre_master_key，pre_shared_key，cli_pub_key，cli_pri_key 等，凡是类似 xxx_pub_key、xxx_pri_key 这种名字的都是一对非对称公私钥，sign_key 和 verify_key 是一对签名/验签的密钥，其他的以 key 结尾的 xxx_key 都是对称密钥。

3.2 Handshake 协议 —- 安全地协商出对称加密密钥

Handshake 协议其实做的最主要的事情就是完成加密密钥的协商，即让通信双方安全地获得一致的对称密钥，以进行加密数据传输。在此基础上，还完成了一些优化工作，如复用 session 以减少握手时间。

在这里说明一下，为什么 mmtls 以及 TLS 协议需要一个 Handshake 子协议和 Record 子协议？其实"认证密钥协商 对称加密传输"这种混合加密结构，是绝大多数加密通信协议的通用结构，在 mmtls/TLS 中 Handshake 子协议负责密钥协商， Record 子协议负责数据对称加密传输。造成这种混合加密结构的本质原因还是因为单独使用公钥加密组件或对称加密组件都有不可避免的缺点。公钥加密组件计算效率往往远低于对称加密组件，直接使用公钥加密组件加密业务数据，这样的性能损耗任何 Server 都是无法承受的；而如果单独使用对称加密组件进行网络加密通信，在 Internet 这种不安全的信道下，这个对称加密密钥如何获取往往是一个难以解决的问题，因此结合两类密码组件的优势，产生了"认证密钥协商 对称加密传输"这种混合加密结构。另外，mmtls/TLS 这种安全性和扩展性都很强的安全通信协议，在解决实际安全通信问题的时候，会有非常多的细节问题，因此分离出两个子协议来隔离复杂性。

3.2.1 带认证的密钥协商

根据 TLS1.3 的描述，实际上有 2 种 1-RTT 的密钥协商方式（1-RTT ECDHE、 1-RTT PSK）和 4 种 0-RTT 的密钥协商方式（0-RTT PSK, 0-RTT ECDH, 0-RTT PSK-ECDHE, 0-RTT ECDH-ECDHE），mmtls 结合微信的特点，在保证安全性和性能的前提下，只保留了三种密钥协商方式（1-RTT ECDHE, 1-RTT PSK, 0-RTT PSK），并做了一些优化，后面会详细分析如何产生这种决策的。

3.2.1.1 1-RTT 密钥协商

1.ECDH 密钥协商

首先看一个，会遭受到攻击的密钥协商过程。通信双方 Alice 和 Bob 使用 ECDH 密钥交换协议进行密钥协商，ECDH 密钥交换协议拥有两个算法：

• 密钥生成算法 ECDH_Generate_Key，输出一个公钥和私钥对 (ECDH_pub_key, ECDH_pri_key)，ECDH_pri_key 需要秘密地保存，ECDH_pub_key 可以公开发送给对方。
• 密钥协商算法 ECDH_compute_key，以对方的公钥和自己的私钥作为输入，计算出一个密钥 Key，ECDH_compute_key 算法使得通信双方计算出的密钥 Key 是一致的。

这样一来 Alice 和 Bob 仅仅通过交换自己的公钥 ECDH_pub_key，就可以在 Internet 这种公开信道上共享一个相同密钥 Key，然后用这个 Key 作为对称加密算法的密钥，进行加密通信。

[1500450304391_2152_1500450305322.jpg]

但是这种密钥协商算法仍然存在一个问题。当 Bob 将他的 Bob_ECDH_pub_key 发送给 Alice 时，攻击者可以截获 Bob_ECDH_pub_key，自己运行 ECDH_Generate_Key 算法 产生一个公钥/私钥对，然后把他产生的公钥发送给 Alice。同理，攻击者可以截获 Alice 发送给 Bob 的 Alice_ECDH_pub_key，再运行 ECDH_Generate_Key 算法 产生一个公钥/私钥对，并把这个公钥发送给 Bob。Alice 和 Bob 仍然可以执行协议，产生一个密钥 Key。但实际上，Alice 产生的密钥 Key 实际上是和攻击者 Eve 协商的；Bob 产生的密钥 Key 也是和攻击者协商 Eve 的。这种攻击方法被称为中间人攻击（Man In The Middle Attack）。

[1500450353732_8281_1500450354367.jpg]

那么，有什么解决办法中间人攻击呢？产生中间人攻击的本质原因是协商过程中的数据没有经过端点认证，通信两端不知道收到的协商数据是来自对端还是来自中间人，因此单纯的"密钥协商"是不够的，还需要"带认证的密钥协商"。对数据进行认证其实有对称和非对称的两种方式：基于消息认证码（Message Authentication Code）的对称认证和基于签名算法的非对称认证。消息认证码的认证方式需要一个私密的 Key，由于此时没有一个私密的 Key，因此 ECDH 认证密钥协商就是 ECDH 密钥协商加上数字签名算法。在 mmtls 中我们采用的数字签名算法为 ECDSA。

双方密钥协商时，再分别运行签名算法对自己发出的公钥 ECDH_pub_key 进行签名。收到信息后，首先验证签名，如果签名正确，则继续进行密钥协商。注意到，由于签名算法中的公钥 ECDSA_verify_key 是一直公开的，攻击者没有办法阻止别人获取公钥，除非完全掐断发送方的通信。这样一来，中间人攻击就不存在了，因为 Eve 无法伪造签名。具体过程如图 5 所示：

[1500450461036_4178_1500450461768.jpg]

事实上，在实际通信过程中，只需要通信中某一方签名它的协商数据就可以保证不被中间人攻击，mmtls 就是只对 Server 做认证，不对 Client 做认证，因为微信客户端发布出去后，任何人都可以获得，只要能够保证客户端程序本身的完整性，就相当于保证了客户端程序是由官方发布的，为认证合法的客户端，而客户端程序本身的完整性不是 mmtls 协议保护的范畴。在这一点上，TLS 要复杂一些，TLS 作为一个通用的安全通信协议，可能会存在一些需要对 Client 进行认证的场合，因此 TLS 提供了可选的双方相互认证的能力，通过握手协商过程中选择的 CipherSuite 是什么类型来决定是否要对 Server 进行认证，通过 Server 是否发送 CertificateRequest 握手消息来决定是否要对 Client 进行认证。由于 mmtls 不需要对 Client 做认证，在这块内容上比 TLS 简洁许多，更加轻量级。

2.PSK 密钥协商

PSK 是在一次 ECDH 握手中由 server 下发的内容，它的大致数据结构为 PSK{key，ticket{key}}，即 PSK 包含一个用来做对称加密密钥的 key 明文，以及用 ticket_key 对 key 进行加密的密文 ticket，当然 PSK 是在安全信道中下发的，也就是说在网络中进行传输的时候 PSK 是加密的，中间人是拿不到 key 的。其中 ticket_key 只有 server 才知道，由 server 负责私密保存。

PSK 协商比较简单，Client 将 PSK 的 ticket{key} 部分发送给 Server，由于只有 Server 才知道 ticket_key，因此 key 是不会被窃听的。Server 拿到 ticket 后，使用 ticket_key 解密得到 key，然后 Server 用基于协商得到的密钥 key，对协商数据计算消息认证码来认证，这样就完成了 PSK 认证密钥协商。PSK 认证密钥协商使用的都是对称算法，性能上比 ECDH 认证密钥协商要好很多。

[1500450529075_4553_1500450529726.jpg]

3.2.1.2 0-RTT 密钥协商

上述的两种认证密钥协商方式（1-RTT ECDHE, 1-RTT PSK）都需要一个额外 RTT 去获取对称加密 key，在这个协商的 RTT 中是不带有业务数据的，全部都是协商数据。那么是否存在一种密钥协商方式是在握手协商的过程中就安全地将业务数据传递给对端呢？答案是有的，TLS1.3 草案中提到了 0-RTT 密钥协商的方法。

1. 0-RTT ECDH 密钥协商

0-RTT 握手想要达到的目标是在握手的过程中，捎带业务数据到对端，这里难点是如何在客户端发起协商请求的时候就生成一个可信的对称密钥加密业务数据。在 1-RTT ECDHE 中，Client 生成一对公私钥 (cli_pub_key, cli_pri_key)，然后将公钥 cli_pub_key 传递给 Server，然后 Server 生成一对公私钥 (svr_pub_key, svr_pri_key) 并将公钥 svr_pub_key 传递给 Client，Client 收到 svr_pub_key 后才能计算出对称密钥。上述过程 (svr_pub_key, svr_pri_key) 由于是临时生成的，需要一个 RTT 将 svr_pub_key 传递给客户端，如果我们能够预先生成一对公私钥 (static_svr_pub_key, static_svr_pri_key) 并将 static_svr_pub_key 预置在 Client 中，那么 Client 可以在发起握手前就通过 static_svr_pub_ke 和 cli_pub_key 生成一个对称密钥 SS(Static Secret)，然后用 SS 加密第一个业务数据包（实际上是通过 SS 衍生的密钥对业务数据进行加密，后面详述），这样将 SS 加密的业务数据包和 cli_pub_key 一起传给 Server，Server 通过 cli_pub_key 和 static_server_private_key 算出 SS，解密业务数据包，这样就达到了 0-RTT 密钥协商的效果。

[1500450565432_3958_1500450566125.jpg]

这里说明一下：ECDH 协商中，如果公私钥对都是临时生成的，一般称为 ECDHE，因此 1-RTT 的 ECDH 协商方式被称为 1-RTT ECDHE 握手，0-RTT 中有一个静态内置的公钥，因此称为 0-RTT ECDH 握手。

2. 0-RTT PSK 密钥协商

0-RTT PSK 握手比较简单，回顾 1-RTT PSK 握手，其实在进行 1-RTT PSK 握手之前，Client 已经有一个对称加密密钥 key 了，就直接拿这个对称加密密钥 key 加密业务数据，然后将其和握手协商数据 ticket{key} 一起传递给 Server 就可以了。

3.提高 0-RTT 密钥协商的安全性

PFS（perfect forward secrecy），中文可叫做完全前向保密。它要求一个密钥被破解，并不影响其他密钥的安全性，反映的密钥协商过程中，大致的意思是用来产生会话密钥的长期密钥泄露出去，不会造成之前通信时使用的会话密钥的泄露；或者密钥协商方案中不存在长期密钥，所有协商材料都是临时生成的。

上面所述的 0-RTT ECDH 密钥协商加密的数据的安全性依赖于长期保存的密钥 static_svr_pri_key，如果 static_svr_pri_key 泄露，那么所有基于 0-RTT ECDH 协商的密钥 SS 都将被轻松计算出来，它所加密的数据也没有任何保密性可言，为了提高前向安全性，我们在进行 0-RTT ECDH 协商的过程中也进行 ECDHE 协商，这种协商方式称为 0-RTT ECDH-ECDHE 密钥协商。如下图所示：

[1500450611835_1769_1500450612834.jpg]

这样，我们基于 static_svr_pri_key 保护的数据就只有第一个业务数据包 AppData，后续的包都是基于 ES(Ephemeral Secret) 对业务数据进行保护的。这样即使 static_svr_pri_key 泄露，也只有连接的第一个业务数据包能够被解密，提高前向安全性。

同样的，0-RTT PSK 密钥协商加密的数据的安全性依赖于长期保存密钥 ticket_key，如果 ticket_key 泄露，那么所有基于 ticket_key 进行保护的数据都将失去保密性，因此同样可以在 0-RTT PSK 密钥协商的过程中，同时完成 ECDHE 密钥协商，提高前向安全性。

3.2.2 密钥协商需要关注的细节

根据前面的描述可以知道，要使得密钥协商过程不被中间人攻击，就必须要对协商数据进行认证。下面拿 1-RTT ECDHE 握手方式来说明在进行认证过程中需要注意的细节。在 1-RTT ECDHE 中的认证方式是使用 ECDSA 签名算法的非对称认证方式，整个过程大致如下：Server 在收到客户端的 cli_pub_key 后，随机生成一对 ECDH 公私钥 （svr_pub_key, svr_pri_key），然后用签名密钥 sign_key 对 svr_pub_key 进行签名，得到签名值 Signature，并把签名值 Signature 和 svr_pub_key 一起发送给客户端。客户端收到之后，用 verify_key 进行验签（verify_key 和 sign_key 是一对 ECDSA 密钥），验签成功后才会继续走协商对称密钥的流程。

上面的认证过程，有三个值得关注的点：

• Verify_Key 如何下发给客户端？这实际上是公钥派发的问题，TLS 是使用证书链的方式来派发公钥（证书），对于微信来说，如果使用证书链的方式来派发 Server 的公钥（证书），无论自建 Root CA 还是从 CA 处申请证书，都会增加成本且在验签过程中会存在额外的资源消耗。由于客户端是由我们自己发布的，我们可以将 verify_key 直接内置在客户端，这样就避免证书链验证带来的时间消耗以及证书链传输带来的带宽消耗。
• 如何避免签名密钥 sign_key 泄露带来的影响？

如果 sign_key 泄露，那么任何人都可以伪造成 Server 欺骗 Client，因为它拿到了 sign_key，它就可以签发任何内容，Client 用 verify_key 去验证签名必然验签成功。因此 sign_key 如果泄露必须要能够对 verify_key 进行撤销，重新派发新的公钥。这其实和前一问题是紧密联系的，前一问题是公钥派发问题，本问题是公钥撤销问题。TLS 是通过 CRL 和 OCSP 两种方式来撤销公钥的，但是这两种方式存在撤销不及时或给验证带来额外延迟的副作用。由于 mmtls 是通过内置·verify_key·在客户端，必要时通过强制升级客户端的方式就能完成公钥撤销及更新。另外，sign_key 是需要 Server 高度保密的，一般不会被泄露，对于微信后台来说，类似于 sign_key 这样，需要长期私密保存的密钥在之前也有存在，早已形成了一套方法和流程来应对长期私密保存密钥的问题。

• 用 sign_key 进行签名的内容仅仅只包含 svr_pub_key 是否有隐患？

回顾一下，上面描述的带认证的 ECDH 协商过程，似乎已经足够安全，无懈可击了，但是，面对成亿的客户端发起 ECDH 握手到成千上万台接入层机器，每台机器对一个 TCP 连接随机生成不同的 ECDH 公私钥对，这里试想一种情况，假设某一台机器某一次生成的 ECDH 私钥 svr_pri_key1 泄露，这实际上是可能的，因为临时生成的 ECDH 公私钥对本身没有做任何保密保存的措施，是明文、短暂地存放在内存中，一般情况没有问题，但在分布式环境，大量机器大量随机生成公私钥对的情况下，难保某一次不被泄露。这样用 sign_key（sign_key 是长期保存，且分布式环境共享的）对 svr_pub_key1 进行签名得到签名值 Signature1，此时攻击者已经拿到 svr_pri_key1，svr_pub_key1 和 Signature1，这样他就可以实施中间人攻击，让客户端每次拿到的服务器 ECDH 公钥都是 svr_pub_key1：客户端随机生成 ECDH 公私钥对（cli_pub_key, cli_pri_key） 并将 cli_pub_key 发给 Server，中间人将消息拦截下来，将 client_pub_key 替换成自己生成的 client_pub_key'，并将 svr_pub_key1 和 Signature1 回给 Client，这样 Client 就通过计算 ECDH_Compute_Key(svr_pub_key1, cli_pri_key)=Key1, Server 通过计算 ECDH_Compute_Key(client_pub_key', svr_pub_key)=Key'，中间人既可以计算出 Key1 和 Key'，这样它就可以用 Key1 和 Client 通信，用 Key'和 Server 进行通信。

发生上述被攻击的原因在于一次握手中公钥的签名值被用于另外一次握手中，如果有一种方法能够使得这个签名值和一次握手一一对应，那么就能解决这个问题。解决办法也很简单，就是在握手请求的 ClientHello 消息中带一个 Client_Random 随机值，然后在签名的时候将 Client_Random 和 svr_pub_key 一起做签名，这样得到的签名值就与 Client_Random 对应了。mmtls 在实际处理过程中，为了避免 Client 的随机数生成器有问题，造成生成不够随机的 Client_Random，实际上 Server 也会生成一个随机数 Server_Random，然后在对公钥签名的时候将 Client_Random、Server_Random、svr_pub_key 一起做签名，这样由 Client_Random、Server_Random 保证得到的签名值唯一对应一次握手。

3.2.3 mmtls 对认证密钥协商的选择

上面一共介绍了 2 种 1-RTT 密钥协商方式和 4 种 0-RTT 密钥协商方式。

[1500450704870_522_1500450705780.jpg]

PSK 握手全程无非对称运算，Server 性能消耗小，但前向安全性弱，ECDHE 握手有非对称运算，Server 性能消耗大，但前向安全性相对更强，那么如何结合两者优势进行密钥协商方式的选择呢？

首先 PSK 是如何获得的呢？PSK 是在一次成功的 ECDH(E) 握手中下发的（在上面的图 7、图 8 没有画出下发 PSK 的部分），如果客户端没有 PSK，那么显然是只能进行 ECDH(E) 握手了。由于 PSK 握手和 ECDH(E) 握手的巨大性能差异，那么在 Client 有 PSK 的情况下，应该进行 PSK 握手。那么在没有 PSK 的情况下，上面的 1-RTT ECDHE、0-RTT ECDH、0-RTT ECDH-ECDHE 具体应该选择哪一种呢？在有 PSK 的情况下，应该选择 1-RTT PSK、0-RTT PSK 还是 0-RTT PSK-ECDHE 呢？

对于握手方式的选择，我们也是几经过修改，最后结合微信网络连接的特点，我们选择了 1-RTT ECDHE 握手、1-RTT PSK 握手、0-RTT PSK 握手。微信目前有两个数据传输通道：1.基于 HTTP 协议的短连接 2.基于私有协议的长连接。

微信长连接有一个特点，就是在建立好 TCP 连接之后，会在此 TCP 连接上先发一个长连 nooping 包，目的是验证长连接的连通性（由于长连接是私有协议，部分中间路由会过滤掉这种私有协议的数据包），这就是说长连接在建立时的第一个数据包是不会发送业务数据的，因此使用 1-RTT 的握手方式，由第一个握手包取代之前的 nooping 包去探测长连的连通性，这样并不会增加长连的网络延时，因此我们选取在长连接情况下，使用 1-RTT ECDHE 和 1-RTT PSK 这两种密钥协商方式。

微信短连接为了兼容老版本的 HTTP 协议，整个通信过程就只有一个 RTT，也就是说 Client 建立 TCP 连接后，通过 HTTP POST 一个业务请求包到 Server，Server 回一个 HTTP 响应，Client 处理后立马断掉 TCP 连接。对于短连接，我们应该尽量使用 0-RTT 的握手方式，因为一个短连接原来就只存在一个 RTT，如果我们大量使用 1-RTT 的握手方式，那么直接导致短连接至少需要 2 个 RTT 才能完成业务数据的传输，导致时延加倍，用户体验较差。

这里存在两种情况：(1) 客户端没有 PSK，为了安全性，这时和长连接的握手方式一样，使用 1-RTT ECDHE；(2) 客户端有 PSK，这时为了减少网络时延，应该使用 0-RTT PSK 或 0-RTT PSK-ECDHE，在这两种握手方式下，由于业务请求包始终是基于 PSK 进行保护的，同一个 PSK 多次协商出来的对称加密 key 是同一个，这个对称加密 key 的安全性依赖于 ticket_key 的安全性，因此 0-RTT 情况下，业务请求包始终是无法做到前向安全性。0-RTT PSK-ECDHE 这种方式，只能保证本短连接业务响应回包的前向安全性，这带来安全性上的优势是比较小的，但是与 0-RTT PSK 握手方式相比，0-RTT PSK-ECDHE 在每次握手对 server 会多 2 次 ECDH 运算和 1 次 ECDSA 运算。微信的短连接是非常频繁的，这对性能影响极大，因此综合考虑，在客户端有 PSK 的情况下，我们选择使用 0-RTT PSK 握手。由于 0-RTT PSK 握手安全性依赖 ticket_key，为了加强安全性，在实现上，PSK 必须要限制过期时间，避免长期用同一个 PSK 来进行握手协商；ticket_key 必须定期轮换，且具有高度机密的运维级别。

另外，为了提高系统可用性，实际上 mmtls 在一次成功的 ECDH 握手中会下发两个 PSK，一个生命周期短保证安全性，一个生命周期长保证可用性。在一次 ECDH 握手中，请求会带上生命周期长的 PSK（如果存在的话），后台可根据负载情况进行权衡，选择使用 ECDH 握手或者 PSK 握手。