报告: 我们继续微信聊天？(简体中文摘要 )

注：本摘要未翻译所有研究发现，请阅读我们的英文报告了解研究发现的详细信息。本摘要仅翻译了完整报告中的“探讨”和“建议”章节。 探讨 “业务层加密”为何重要？

By Mona Wang, Pellaeon Lin, and Jeffrey Knockel 

2024年10月15日

阅读英文报告 重要发现 (https://citizenlab.ca/2024/10/should-we-chat-too-security-analysis-of-wechats-mmtls-encryption-protocol )

• 微信拥有超过十亿月活跃用户，我们分析了微信使用的主要网络协议MMTLS的安全性和隐私特性，并发布了首篇公开研究报告。
• 我们发现MMTLS实际上是修改自TLS 1.3协议，微信开发者在其中修改了部分加密机制，并在某些修改中引入了漏洞。
• 进一步分析发现，早期版本的微信使用了一种不同且更不安全的自制协议，称为“业务层加密”。业务层加密包含多个安全漏洞，在我们测试的新版本微信中，业务层加密与MMTLS同时被使用。
• 虽然我们没有找到完全破解微信网络加密的方法，但其加密仍存在一些弱点，例如使用了确定性的初始化向量（Initialization Vector），且缺乏前向保密特性（forward secrecy）。对于一款拥有十亿以上用户的应用程序，其安全性仍有待提高。
• 近期一些其他研究指出，中国市场中的应用程序经常不遵循密码学界公认的最佳实践，而选择开发自制的加密系统，这些系统往往存在大小不一的漏洞。本研究为这一现象提供了更有力的证据。
• 我们在研究中开发的工具程序和技术方法文件，已在我们的GitHub存储库中发布。这些工具程序和技术文件将有助于其他研究人员进一步探索微信系统的内部工作方式。

既然我们已经在报告中提到，业务层加密外面会再包裹一层较为安全的MMTLS加密，那么业务层加密即使不安全，又会有什么实质影响？在腾讯回复我们的信件中，主要提到的是业务层加密的各种问题，信中也暗示了他们正在逐步将业务层加密中有问题的AES-CBC加密法替换为AES-GCM，这表明腾讯对业务层加密的问题有所顾虑。

首先，我们研究了旧版微信（v6.3.16, 2016发布），当时业务层加密是微信传输网络数据的唯一一层加密。其次，由于业务层加密会将内部的请求网址未加密暴露，我们猜测微信设计的服务器端架构中可能由不同内部服务器端点来处理不同类型的网络请求（不同类型的网络请求包含不同的“requestType”数值，以及不同的“cgi-bin”网址）。例如，微信的服务器端架构可能由最外层的服务器端点来解开MMTLS加密，再根据不同的请求类型将内部请求转发至负责的内部服务器端点（转发时不再重新加密，仅依赖业务层加密提供的安全性）。在这种假设的架构下，如果微信内部网络中存在网络窃听者，它们将可以直接攻击这些被转发请求所使用的业务层加密。 

为何不直接使用TLS？

根据腾讯自行公开的技术文件以及我们研究的验证，MMTLS（微信所使用的“外层”加密）主要是基于TLS 1.3。该技术文件显示MMTLS的设计者对非对称加密法有深入理解。

文件中解释了不使用TLS的理由：因为微信大多数的网络数据传输只需在一次请求和响应循环中完成（中国业内称为“短连接”），因此特别需要底层协议的0-RTT特性。MMTLS只需一来一回的下层TCP包建立TCP连接，即可立即开始传输数据，相比之下，TLS 1.2在TCP连接建立后需要增加一次来回的TLS握手才能开始传输数据。

虽然TLS 1.3草案标准中提出了0-RTT（不增加网络延迟）建立安全连接的方法，此外TLS协议通过版本号、CipherSuite、扩展机制提供了良好的可扩展性。然而，TLS 1.3草案标准当时仍在制定过程中，基于标准的实现也遥遥无期，并且TLS 1.3是一个针对所有软件制定的通用协议，如果结合微信自身特点，仍有很大的优化空间。因此最终选择基于TLS 1.3草案标准，设计了我们自己的安全通信协议MMTLS。

然而，即使在该文件撰写的2016年，TLS 1.2也已提供了会话恢复（session resumption）的功能。更有甚者，即使当时TLS 1.3在IETF协议制定流程中仍属草案，若微信需要会话恢复功能，由于微信对服务器端和客户端代码拥有完全控制权，部署当时仍在测试中的TLS 1.3实现并非难事。

尽管MMTLS设计者付出了大量努力，总体来看，微信所使用的安全协议在安全性和性能上均不如TLS 1.3。一般情况下，设计一套既安全又高效的传输协议并非易事。

传输协议为了进行握手而使用额外的包来回造成延迟，这一问题长期困扰着应用程序开发者。TCP和TLS的握手流程各自需要一次包来回，意味着在传输任何新数据之前，协议需要等待两次包来回，造成延迟。如今，已有如TLS-over-QUIC等协议，结合了传输层和加密层的握手，仅需一次包来回即可完成握手开始传输数据。QUIC提供了一种兼顾安全性和高效性的解决方案，同时具备强健的前向保密加密（forward secrecy），并减少了先前协议建立连接所需的包来回次数。我们建议微信改用标准的QUIC协议。

最后，除了考虑网络性能，客户端应用程序的性能也是一个重要课题。微信的协议设计中，每个网络请求都需要进行两层加密，这意味着相比于行业标准协议只需一次加密，微信客户端应用程序需要花费近乎两倍的计算资源和时间。

中国应用程序自制加密法的趋势

本研究的发现与我们早先的研究结果共同指出了一项趋势：中国应用程序广泛地使用自制的加密法。通常，选择不使用行业标准的TLS，并开发自制的非标准加密法，与行业公认的安全最佳实践背道而驰。尽管在TLS普及的早期（2011年）存在一些合理的对TLS不信任的原因，例如EFF和Access Now对证书签发机构生态系统的担忧，TLS的发展在之后已经基本稳定，机制变得更加透明且可审计。

如同MMTLS，我们过去研究过的所有自制协议相较于TLS都存在一些安全漏洞，在某些情况下，这些自制协议甚至可能被网络攻击者轻松破解。全球互联网的发展趋势正逐步普及国际标准的QUIC和TLS以保护数据传输，而中国行业的这种背离趋势令人担忧。