LWN: 通用计算的未来！

关注了就能看到更多这么棒的文章哦～

The future for general-purpose computing

By Jake Edge
December 9, 2020
DeepL assisted translation
https://lwn.net/Articles/839397/

毫无疑问，通用计算(general-purpose computing)是世界的福音。在我们拥有的许多（大部分）计算设备上，能够运行来自各种不同地方的程序，包括从公司购买的、从头开始编写的、以及从源代码构建的，这是我们认为理所当然的事情。但是，这种模式正在许多种类设备中不再存在了，包括个人电脑也类似，最近苹果公司的一场风波就证明了这一点。

11 月中旬开始，macOS 用户突然发现在系统上难以启动应用程序。启动一个应用程序需要几分钟的时间，而且这个事件似乎与同一天发布的 macOS "Big Sur" 有关系。原来，是苹果的在线证书状态协议(OCSP，Online Certificate Status Protocol)服务器不堪重负（或因为其他什么原因）而无法正常工作，从而导致了这些问题。

OCSP 是验证 macOS 上应用程序是否可信的过程中的一部分，这些应用程序会用开发者的密钥进行签名。苹果会对开发者的公钥进行签名，公钥包含在证书之中，这就类似于 TLS 使用那些。不过系统需要进行检查来确保密钥没有被撤销（revoke）。这项检查会在安装时进行，然后在每次运行应用程序时也会进行。

通常情况下，如果 OCSP 服务器因为宕机，或者系统没有连接到互联网，这个连接就会失败，这被视为 "soft failure"，证书仍被认为是有效的。这样一来，应用程序就会立即打开。不过在这次的事件期间，服务器虽然都正常启动了，但没有回复正确内容，所以应用程序不会启动，一直到连接超时。这次事件让人们更加注意到了 OCSP 检查，其实这个 OCSP 检查在 macOS 中已经进行了一段时间了。

这次故障导致了 Jeffrey Paul 发表了一篇相当夸张的博客文章 (https://sneak.berlin/20201112/your-computer-isnt-yours/)，指出了 OCSP 的一些重大隐私缺陷，尤其是 macOS Gatekeeper 在运行应用程序之前为确保应用程序具有有效签名而进行的检查，其中就有缺陷。每当一个连接互联网的 macOS 系统启动一个应用程序时，会发送一条包含私人信息的 OCSP query 就会被发送到苹果公司。很明显，服务器知道请求发出的日期和时间，以及发出请求的 IP 地址。后者可以大致确定这个系统的地理位置。还有一个根据被查询的证书算出的哈希值，保罗简单称之为 "application hash"。所有这些信息都提供给了苹果公司，而人们可能并不想向公司提供这些数据。并且 OCSP 查询是通过未加密的 HTTP 进行的。因此，任何能够看到这些网络数据的人（比如 ISP 即服务提供商、政府间谍机构、WiFi 热点提供商）也同样能看到用户正在运行哪些应用、何时运行、以及在哪里运行。

保罗的分析有些缺陷（正如 Jacopo Jannone 和其他一些人所指出的），因为发送的哈希值是针对开发者证书的，而不是应用程序本身。在很多情况下，这两者可能没有什么区别，因为开发者只发布了一个应用程序。OCSP 检查并没有直接发送能跟应用程序一一对应的哈希。它发送的信息对于苹果、它的内容分发网络（CDN）合作伙伴 Akamai 以及任何能够看到网络数据包的 "中间人" 来说还是相当有用的。此外，还要考虑美国和其他国家的政府，它们可以（而且确实）定期要求提供此类记录，都不需要搜查令。

从某种意义上说，这对隐私的影响与网络浏览器的情况并没有什么不同，网络浏览器也使用 OCSP 来确定 HTTPS 网站的 TLS 证书是否已经被撤销。它们使用 OCSP 也是不加密的，因为要通过 HTTPS 确定证书有效性的话，会有一个先有鸡还是先有蛋的问题。OCSP stapling (https://en.wikipedia.org/wiki/OCSP_stapling) 技术在一定程度上有助于解决这个问题。不过这两者也有很大的区别，所有的 macOS 应用的 OCSP 检查都会发给苹果服务器，而对网站证书有效性的检查则会发给各个证书颁发机构（CA），而不是唯一一个公司。

针对 OCSP 服务器故障以及保罗的文章、杰夫-约翰逊（Jeff Johnson）的这条 Twitter 信息(https://twitter.com/lapcatsoftware/status/1326990296412991489)等引起的骚动，苹果发表了一份关于安全检查的声明。作为其中的一部分，该公司承诺停止从 OCSP 检查中收集 IP 地址，并创建一个新的加密协议来做检查，并为用户提供一个选项可以选择不参与这个检查。

一般来说，在运行程序之前检查程序的完整性（注：integrity，不仅指完整，也指未被篡改）当然是一件好事，但魔鬼就存在于细节之中。一些人坚信，苹果为保护用户及其电脑的安全做出了正确的决定，但确保这种安全是有代价的。苹果实际上可以决定哪些程序可以安装和运行在 macOS 系统上，至少对大多数用户来说是这样。如果开发者以某种方式来糊弄苹果公司，他们的证书就会被撤销。如果开发者不想征得苹果的许可（也就是不申请开发者证书），那么他们的应用程序根本无法安装和运行。

显然，现在有一些设置选项和其他机制可以绕过这些检查，这样做的话就是一把双刃剑。一方面，它将系统的控制权还给了硬件的所有者，但另一方面，它又使上述所有者面临着许多令人不快的风险。参照《the Gripping Hand》，很担心这些机制可能会随着时间的推移而消失。三刃剑存在吗？

例如，一个名为 Little Snitch 的工具已经被用来绕过 OCSP 检查，但在这次的新版本 Big Sur 中，它已经不再有效了。苹果公司允许它的一些应用程序可以不必通过第三方防火墙程序（如 Little Snitch）框架。这使得这些程序可以躲过防火墙，甚至不经过 VPN。事实上这是一个从硬件所有者手中夺取控制权的好办法。

也许更糟糕的潜在风险是，基于苹果的 Arm 新硬件可能会被 lockdown。其他的基于 Arm 的苹果设备(如 iPhone、iPad)都已经被 lockdown 了，这样只有苹果认可的操作系统才能安装在上面。那些新的 macOS 系统将只能运行 Big Sur 版本，因此购买这些硬件的使用者实际上无法通过防火墙或 VPN 来禁止那些认证用的网络数据。如果苹果坚持要对基于 Arm 的硬件进行 lockdown，那么在购买这些硬件的时候，这些买家到底 "拥有"了什么（译者注：意指没有拥有对硬件的完全控制权力）。

在一个 Twitter 帖子(https://twitter.com/dhh/status/1328337941769367552)中，Ruby on Rails 的创造者 Dave Heinemeier Hansson 很好地总结了这个问题：

整个过程中，苹果公司将 "防止恶意软件而进行保护" 以及 "保护自己的商业模式" 这两点混在一起，这存在很大的问题。苹果的目的很明显，App Store 很快就会成为唯一的 "可信任" 的默认平台。和 iOS 一样，将 Mac 也 lock 起来。

我们需要保持警惕，对这些纯粹伪装成善意的安全措施而掠夺我们的权力的行为需要抵制。Yes，他们做法在安全方面有好处。No，我们不信任苹果，不可以让它来决定我们的电脑是否应该被允许运行一个软件。我们已经在 iOS 上失去了这个自由。

自由软件（free software）是未来的一条出路，这是当然的，但它需要能够在设备上按照主人的选择来安装和运行软件。这在某些场景下可能不太安全，但它显然更自由（就是 freedom 所指的自由）。这对于那些懂技术的人来说是有意义的，但遗憾的是可能会把我们不太懂技术的朋友、邻居和家人抛在脑后。保护这些人，又不用强迫他们买进这样或那样的围墙里的花园，是一个很难破解的问题。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～