我下载最近的 Apple 安全更新时发生了什么?

信息安全 tls 中间人 苹果系统 更新 监视
2021-08-20 18:24:57

有问题的更新是 Mavericks 组合更新,除其他外,它声称修复了最近的 SSL 漏洞/漏洞。

这个问题真的让我很恼火,所以我决定购买 Apple 的 PGP 密钥并尽我所能进行验证。在下载过程中,我使用 Wireshark 窥探了我的流量。以下是我的发现:

  • 获取和验证 Apple 的 PGP 密钥是浪费时间,因为据我所知,他们不会为软件更新发布签名
  • 更新下载器通过 HTTPS 连接到他们的软件下载定位器域,该域重定向到 CDN 上的实际更新(在我的例子中是 apple.vo.llnwd.net)
  • 更新包的每一点都来自 CDN 的普通旧 HTTP
  • 每个更新的数据包后跟一个重复的 ACK(这只发生在更新中,我所有其他下载都很好,所以我不认为这是我的基础设施)
  • 默认情况下,从此处手动下载 dmg 存档是 HTTP。强制 HTTPS 会导致重定向到实际 (HTTP) 文件 URI,不会为该 URI 启用 HTTPS。

苹果(大概是对过去的批评作出回应)明确表示,更新是通过 HTTPS 传递的,除非“复杂的代理设置”使这成为不可能。我试图通过我的香草连接和 2 个离岸 VPN 下载,为了爱和金钱,我无法获得指向该文件的 HTTPS 链接(软件更新或通过网站)。

我的问题是:

  1. 在你看来,他们 - 或者介于两者之间的人 - 玩有趣的虫子?
  2. 所有这些重复的 ACK 是否值得怀疑?(我对此知之甚少,甚至无法推测)

我很怀疑,因为如果我是 NSA/GCHQ 并且我有一周的警告要拦截和替换可预测的 HTTP 端点上的二进制块,因为数百万目标机器上的代码签名完全被破坏,我可能会自动执行认为圣诞节来了两次。如果他们有能力的话,我看不出任何情况下他们可以放弃这样的机会,而且从我读到的所有内容来看,他们完全有能力做到这一点。

1个回答

(以下都是猜测,我不知道苹果的更新程序在内部是如何工作的。)

肯定有一些架构可以通过 HTTP 执行安全更新。几乎所有 Linux 发行版都以明文形式分发包,并通过验证存储库元数据中的哈希值(SHA-1、SHA-256 等)来验证它们。反过来,存储库元数据使用您的主机验证的 GPG 密钥进行签名,并使用您的原始安装介质进行安装。(如果您的原始安装媒体是后门的,那么所有的赌注都将永远关闭。)

那么这与您的 Apple 更新有什么关系呢?苹果可能会使用类似的方案——通过 HTTPS 发送散列,通过 HTTP 下载,然后验证散列。像这样的软件更新是你真正需要的是完整性的情况(我知道有些人想要保密,但老实说,如果攻击者看到你通过 HTTPS 从 apple.com 下载 X 字节,并且最新的苹果更新是 X字节,您已经失去了机密性),并且可以在不通过 HTTPS 发送文件本身的情况下实现完整性。

事实上,这种技术可能更可取——Apple 可以有少量服务器在其直接控制下提供更新元数据(即更新的 URL 和哈希),然后使用第 3 方 CDN 分发更新,从而降低带宽成本,延迟等。如果更新由 CDN 直接通过 HTTPS 提供而没有验证步骤(即,所有完整性都来自 HTTPS),那么 CDN(或破坏 CDN 的人)可以用修改后的版本替换更新。

重复的 ACK 是否值得担心在很大程度上是一个单独的问题。我的关注程度取决于很多事情:它们是出站还是入站 ACK?什么是 TTL?序号是多少?这真的很难说,但我怀疑重复的 ACK 更可能是由某处的网络配置错误(即使不是您的网络)引起的,而不是由攻击者引起的。