如何在坚持原创、国产替代的同时，保持技术领先，以及遵循国际上最佳实践？
该文主要贡献（点击标题）
- 我们首次公开分析了 MMTLS 的安全性和隐私属性，MMTLS 是微信使用的主要网络协议，微信是一款每月活跃用户超过 10 亿的应用程序。
- 我们发现 MMTLS 是 TLS 1.3 的修改版本，微信开发人员对加密技术所做的许多修改都引入了弱点。
- 进一步分析发现，早期版本的微信使用了一种安全性较低、定制设计的协议，其中包含多个漏洞，我们将其描述为“业务层加密”。在现代微信版本中，除了 MMTLS 之外，仍使用这一层加密。
- 虽然我们无法开发出一种能够完全破解微信加密的攻击方式，但其实现方式与十亿用户使用的应用程序中所期望的加密级别不一致，例如其使用确定性 IV 和缺乏前向保密性。
- 这些发现有助于进一步研究中国生态系统中的应用程序未能采用最佳加密实践，而是选择发明自己的、往往存在问题的系统。
- 我们将在配套的Github 存储库中发布技术工具和有关我们技术方法的进一步文档。这些工具和文档以及本主要报告将帮助未来的研究人员研究微信的内部工作原理。
MMTLS 加密问题
1、确定性 IV
MMTLS 加密过程每次连接生成一个 IV。然后，它们会为该连接中加密的每个后续记录增加 IV。通常，NIST建议不要在 AES-GCM 中使用完全确定性的 IV 派生，因为很容易意外重复使用 IV。在 AES-GCM 的情况下，重复使用 (key, IV) 元组是灾难性的，因为它允许从 AES-GCM 身份验证标签中恢复密钥。由于这些标签附加到 AES-GCM 密文以进行身份验证，因此可以从使用相同密钥和 IV 对加密的少至 2 个密文中恢复明文。
此外，Bellare 和 Tackmann还表明，使用确定性 IV 可以让强大的对手暴力破解特定的 (密钥，IV) 组合。如果加密系统部署到非常大的（即互联网大小）所选 (密钥，IV) 组合池中，则这种类型的攻击适用于强大的对手。由于微信拥有超过 10 亿用户，因此这种数量级使这种攻击处于可行性范围内。
2、缺乏前向保密
现代通信协议通常都要求具有前向保密性，以降低会话密钥的重要性。一般来说，TLS 本身在设计上就是前向保密性的，但“恢复”会话的第一个数据包除外。第一个数据包使用“预共享密钥”或上次握手期间建立的 PSK 进行加密。
MMTLS 在设计上大量使用 PSK。由于 Shortlink 传输格式仅支持单次往返通信（通过单个 HTTP POST 请求和响应），因此通过传输格式发送的任何加密数据都使用预共享密钥加密。由于泄露共享的 PSK_ACCESS 密钥将使第三方能够解密通过多个 MMTLS 连接发送的任何 EarlyData，因此使用预共享密钥加密的数据不是前向机密。通过 MMTLS 加密的绝大多数记录都是通过 Shortlink 传输发送的，这意味着微信发送的大多数网络数据在连接之间不是前向机密。此外，在打开应用程序时，微信会创建一个长寿命的 Longlink 连接。这个长寿命的 Longlink 连接在微信应用程序的持续时间内都是打开的，任何需要发送的加密数据都通过同一连接发送。由于大多数微信请求要么使用（A）会话恢复 PSK 或（B）长寿命 Longlink 连接的应用程序数据密钥加密，因此微信的网络流量通常不会在网络请求之间保留前向保密性。
3、业务层加密问题
业务层加密结构，尤其是对称模式 AES-CBC 结构本身存在许多严重问题。由于微信发出的请求是双重加密的，这些问题只影响内部业务层加密，因此我们没有找到立即利用它们的方法。然而，在仅使用业务层加密的旧版微信中，这些问题是可以被利用的。
- 元数据泄露：业务层加密不会对用户ID、请求URI等元数据进行加密，具体细节在“业务层请求”一节中提到。这个问题也被微信开发者们自己承认，也是开发MMTLS加密的动机之一。
- 可伪造的 genSignature 完整性检查：可以伪造长度为evil_sig的签名
- 分组密码模式下密钥、IV 重复使用：重复使用两者意味着如果两个明文相同，它们将加密为相同的密文。
- 加密密钥问题：服务器选择客户端使用的加密密钥是非常不合常规的。事实上，我们注意到服务器生成的加密密钥（“会话密钥”）仅使用可打印的 ASCII 字符。因此，即使密钥长度为 128 位，该密钥的熵也最多为 106 位。
为什么业务层加密很重要？
既然业务层加密被包裹在 MMTLS 中，那么它是否安全又有什么关系呢？首先，从我们对微信早期版本的研究来看，业务层加密是微信网络请求的唯一加密层，直到 2016 年。
其次，从业务层加密暴露未加密的内部请求 URI 的事实来看，微信的可能架构之一是托管不同的内部服务器来处理不同类型的网络请求（对应不同的“requestType”值和不同的 cgi-bin 请求 URL）。
例如，在前端微信服务器（处理 MMTLS 解密）终止 MMTLS 后，转发到相应内部微信服务器的内部微信请求不会被重新加密，因此仅使用业务层加密进行加密。微信内联网中的网络窃听者或网络分路器可能会攻击这些转发请求上的业务层加密。
然而，这种情况纯粹是推测性的。腾讯对我们披露的回应涉及业务层加密中的问题，并暗示他们正在慢慢从问题更大的 AES-CBC 迁移到 AES-GCM，因此腾讯也对此感到担忧。
建议微信迁移到标准 QUIC 实现
TCP 和 TLS 握手都需要一次往返，这意味着发送的每个新数据包都需要两次往返。如今，TLS-over-QUIC 结合了传输层和加密层握手，只需要一次握手。QUIC 兼具两全其美的优势，既提供了强大的前向秘密加密，又将安全通信所需的往返次数减少了一半。
除了网络性能之外，还有客户端性能的问题。由于微信的加密方案对每个请求执行两层加密，因此客户端加密数据的工作量是使用单一标准化密码系统的两倍。
国产密码技术在中国的应用趋势
避免使用 TLS 并偏爱专有和非标准加密技术背离了加密最佳实践。
随着全球互联网逐渐转向使用 QUIC 或 TLS 等技术保护传输中的数据，这是一种日益增长且令人担忧的趋势，仅出现在中国安全领域。
反DNS劫持机制
和腾讯编写自己的加密系统类似，我们发现在 Mars 中腾讯也编写了一个专有的域名查找系统。这个功能在 Mars 中被称为“NewDNS”。根据我们的动态分析，这个功能在微信中经常使用。乍一看，NewDNS 重复了 DNS（域名系统）已经提供的功能，而 DNS 已经内置在几乎所有联网设备中。
微信并不是中国唯一一款使用此类系统的应用程序。中国的主要云计算提供商（如阿里云和腾讯云）都提供自己的 DNS over HTTP 服务。
采用这种系统的一个可能原因是，中国的 ISP 经常实施DNS 劫持来插入广告并重定向网络流量以进行广告欺诈。这个问题非常严重，以至于六家中国互联网巨头于 2015 年发表联合声明，敦促 ISP 改进。
与 MMTLS 加密系统类似，腾讯的 NewDNS 域名查询系统旨在满足中国网络环境的需求。多年来，DNS 本身已被证明存在多个安全和隐私问题。
与 DNS 本身相比，NewDNS 是否存在更多或更少的问题仍是一个悬而未决的问题。我们将这个问题留待将来研究。
Mars STN 在微信之外的使用
微信之外对 Mars 的采用令人担忧，因为 Mars 默认不提供任何传输加密。
基于以下观察，我们推测 Mars（mars-open）在微信之外也有广泛的应用：
- Mars GitHub 存储库中存在许多问题。
- 有大量 技术概述了如何使用 Mars 构建即时通讯系统。
- 目前已经有基于Mars的白标即时通讯系统产品。
Mars 的文档也比较缺乏。官方wiki上只有几篇关于如何与 Mars 集成的旧文章。使用 Mars 的开发人员通常求助于在 GitHub 上提问。缺乏文档意味着开发人员更容易犯错，最终降低安全性。
背景
公民实验室是位于加拿大多伦多的多伦多大学蒙克全球事务与公共政策学院的一个学术研究小组。
- 该小组2024 年 4 月 24 日披露了微信的专有网络加密协议 MMTLS 与现代网络加密协议（如 TLS 或 QUIC+TLS）相比存在弱点。
- 2024 年 5 月 17 日——腾讯的回应：微信的安全协议核心是外层mmtls加密，目前确保外层mmtls加密是安全的。另一方面，内层的加密问题处理如下：核心数据流量已切换到AES-GCM加密，其他流量正在逐步从AES-CBC切换到AES-GCM。
版权归原作者 极道Jdon 所有， 如有侵权，请联系我们删除。