mitmproxy 添加了 --emudhra 选项

原文 ↗ Hacker News 讨论 ↗

mitmproxy 新增了一个 `--emudhra` 选项，利用最近公开的、弱到几乎可忽略不计的 eMudhra 中间 CA 密钥——其中一个密钥甚至就是数字 4——来生成许多较旧或未修补设备仍会信任的 HTTPS 证书。评论者讨论了这如何让人透明拦截旧 Android 手机、智能电视和 IoT 设备的流量，同时也强调了 iOS 和 macOS 等平台在证书撤销与信任存储更新方面的普遍失灵。此事件引发了关于 CA 治理、潜在后门、此类工具的负责任使用，以及在这类失误如此严重的情况下，公开羞辱证书颁发机构是否正当的讨论。

mitmproxy 中的新 --emudhra 功能

  • 该选项使用如今已公开的 eMudhra 中间密钥之一，对拦截到的 TLS 证书进行签名。
  • 其目的是提供一种实用方式，用来测试哪些设备和应用程序仍然信任这些已失陷的证书链。
  • 有人建议整合多条已失陷的链（emSign 和 AAA 路径）以扩大覆盖范围；文中附有一个合并请求链接。

用例：调试、逆向工程、越狱

  • 对以下场景的使用反响热烈：
    • 较旧的 Android 手机（如果应用没有证书固定或使用自己的信任存储）。
    • 智能电视和 IoT 设备，用于观察厂商流量、配置或固件更新。
  • 描述了 mitm 流程：拦截配置/固件/广告通道，这些通道可能启用开发模式或导致 RCE。
  • 局限性：证书固定、证明机制、私有根证书，以及已经更新或撤销信任的设备。

eMudhra 失陷的细节

  • 有八个中间 CA 使用了荒谬地弱的 P-384 私钥；给出的示例（4、56、66 等）实际上只有 3–8 位熵。
  • 一些解释认为，这看起来像是原本应为 384 位的地方误用了 8 位密钥。
  • 涉及的根证书包括：emSign ECC Root CA – G3 和一个较旧的 AAA 根证书；文中讨论了它们分别何时进入/退出主要信任存储的时间线。
  • 还指出椭圆曲线密钥搜索大约需要 2^(n/2) 的工作量，这使得“中度弱”的 EC 密钥可以在 GPU 上被暴力破解。

平台撤销行为（尤其是 Apple）

  • 多位用户报告称，在 iOS、iPadOS 和 macOS 上访问测试站点时结果不一致：
    • 有人看到所有链都被阻止。
    • 也有人仍然看到 1–3 条伪造链被接受。
  • 猜测原因包括分阶段推送、OCSP/CRL 查询失败，或超时；行为仍不明确。
  • 在 macOS 钥匙串中手动取消对根证书的信任，能够可靠地阻止这些坏链。

伦理、命名与更广泛的安全主题

  • 对将该选项命名为 --emudhra 的看法不一：
    • 有人认为这是对严重 CA 失误的公平问责。
    • 也有人认为这是在“加重”那些“永远摆脱不了这件事”的个人的负担。
  • 多条评论将此描述为“把一场安全灾难转化为防御工具”，使用户能够检查并控制厂商试图锁定的设备。
  • 文中提到有人建议系统性扫描所有 CA 是否存在类似弱密钥；另有回复指出，这个具体问题是使用现有工具发现的，而在那次扫描中没有观察到其他弱密钥。