整理 | 夕颜

　　出品 | CSDN(ID:CSDNnews)

　　近日，苹果在发布会上推出了数款专用芯片M1支持的Mac新品，包括Mac book、MacBook Pro和Mac mini系列。随之一起重磅发布的，还有macOS 11.0，也就是大家熟知的Big Sur正式版。

　　然而，当用户上手体验时，却发现Big Sur下载过程缓慢，而且出现突然中断的情况，必须重启设备。与此同时，苹果的开发者网站也发生问题，导致部分第三方应用程序无法打开。

　　这些问题似乎出现在新版Big Sur推出之际，并影响了其他版本的macOS用户，比如Catalina和Mojave。其他的Apple服务，包括Apple Pay, Messages甚至Apple TV 也发生了缓慢、中断和不正常的现象。

　　不久之后，一些Mac用户还发现，当尝试用trustd(一个负责与Apple的服务器进行核对，以确认应用程序是否经过认证的MacOS进程)与ocsp.apple.com联系时，发生反复失败的情况。这导致App启动时发生系统性大规模的速度降低。

　　有用户反馈，打开控制台并进行过滤以查找错误的用户，遇到了许多与Trusted相关的连续错误，如下图所示。

　　trustd负责核实Developer ID证书的状态，而不是公证。但这不是重点。关键是，当Apple的CDN掉线时，Apple的OCSP服务器停止响应，并且当这种情况发生时，许多联网的Mac就会停止工作。

　　trustd进程只是为了在没有联网情况下继续运行，并非是为了处理trustd可以连接Apple的OCSP服务器，但服务器没有响应的情况。

　　事故发生时，很多Mac用户完全不知道为什么他们的应用启动不了，还担心是不是操作系统或者硬件出了问题。

　　苹果回应故障原因，更新支持文档

　　昨日，苹果对这场“意外”进行了官方回应，称导致OCSP服务器出现问题的原因，是由于服务器端的错误配置，特别是干扰了macOS能够为开发者ID缓存OCSP响应。这个配置错误，以及一个不相关的内容传输网络(CDN)的错误配置，是导致应用程序启动性能缓慢的原因。苹果表示，目前已通过服务器端更新修复了这一性能问题，现在将允许macOS在更长的时间内缓存开发者ID OCSP检查，macOS用户不需要任何操作。

　　在支持文档更新中，苹果解释了“门禁(Gatekeeper)的用处，并给出了解决问题的详细步骤，具体可参考https://support.apple.com/en-us/HT202491

　　苹果表示，“从未将这些检查的数据和苹果用户或者他们的设备捆绑，不会使用这些检查的数据来了解个人用户在其设备上启动或运行的内容，”并强调“公证检查应用程序是否包含已知的恶意软件，使用的是对服务器故障有弹性的加密连接。这些安全检查从未包含用户的Apple ID或其设备的身份。为了进一步保护隐私，我们已经停止记录与开发者ID证书检查相关的IP地址，我们将确保从日志中删除任何收集到的IP地址”。

　　此外苹果还承诺在接下来的一年时间里，将会对安全检查进行一些调整，具体包括：

　　● 一个针对开发者 ID 的全新加密协议，用于验证该 ID 是否被撤销;

　　● 强大的保护措施，防止服务器故障;

　　● 用户可以选择不接受这些安全保护的新偏好。

　　至此，这场波及全球数百万台Mac设备的事故引发的争议似乎要告一段落了，但在这个过程中，一些网友针对macOS出现问题的解决办法，以及关于macOS安全隐私问题的争议，也值得探讨一下。

　　这究竟是怎么回事呢?

　　用第三方防火墙，但被指存在安全隐患

　　话说是在Big Sur正式版发布之后一些Mac设备打开第三方App出现卡死现象后不久，就有万能的网友在就找到了应对这个bug的方法，那就是让用户使用第三方防火墙软件，比如LuLu、Little Snitch等。这些应用可以连接到ocsp.apple.com，绕过认证环节，直接下载App。

　　提出这个方法的是Jeff Johnson，这是一位拥有数十年MacOS和iOS开发经验的开发者。因为针对这件事频频在Twitter发声，Jeff Johnson一时成了网络红人。

　　然而，虽然Jeff Johnson提出的方法能奏效，但这种方法其实存在着巨大的安全隐患。一名黑客&安全研究员Jeffrey Paul的文章Your Computer Isn't Yours 尤其引起了广泛的关注。在文中，他指出macOS一些现存机制已经严重地影响了用户的隐私安全。

　　什么是OCSP?

　　为什么用第三方防火墙会引发安全隐患?首先，我们需要搞清楚什么是OCSP。

　　OCSP(Online Certificate Status Protocol)意为在线证书状态协议。顾名思义，它用于验证证书的有效性，而不必下载和扫描大型证书吊销列表。启动Mac应用程序时，macOS使用OCSP来确保在应用程序在启动之前未被吊销开发人员证书。

　　自2012年以来，macOS(当时称为Mac OS X)要求从Web下载的所有应用程序(Mac App Store外部)都必须使用由Apple颁发给开发人员的有效Developer ID证书进行签名。苹果认为，Developer ID的目的是防止恶意软件传播，开发人员已分发恶意软件一旦被发现，Apple就撤销该开发人员的代码签名证书，macOS也将阻止启动任何使用该证书签名的软件，从而保护Mac用户。

　　但这个证书有一点不好，如果Developer ID OCSP的互联网连接出现问题，可能会阻止Mac应用程序启动。在上周四Big Sur发生故障的的几个小时中，全世界数百万台Mac在启动安装的应用程序时都遇到了极其缓慢的情况，可以称得上是一次短暂的重大计算灾难。

　　绕过防火墙，留下安全隐患

　　可以看到，苹果Developer ID OCSP的初衷就是为了保证应用程序的安全性。在之前的macOS版本中，会用网络内核拓展构建防火墙，但是新版系统中，苹果弃用了这些拓展，导致很多App可以绕过防火墙，直接下载。如果使用第三方软件绕过防火墙，macOS无法触动Apple的OCSP响应程序，就将跳过检查，直接启动该应用程序。这本质上是一种出故障时自动打开的机制，意味着下载的App安全性根本无从保证。

　　这个机制要求macOS在启动应用程序之前与Apple联系，这时与ocsp.apple.com失联，苹果的响应程序并没有失效，用户虽然可以触动响应程序，但过程变得非常缓慢。

　　macOS运行时向Apple发送每个程序的哈希值?

　　拔出萝卜带出泥，在研究Developer ID OCSP的过程中，安全研究员 Jeffrey Paul发现了一个漏洞，会威胁到用户的隐私安全。

　　他在文章中声称，在当前版本的macOS中，操作系统在运行时，会向Apple发送用户运行的每个程序的哈希值(唯一标识符)!很多人没有意识到这一点的严重性，只要用Mac联网，任何连接服务器的第三方都可以看到你的IP、输入时间，并进行粗略的城市及和ISP级地理定位，也可以为通用程序计算这些哈希值，包括App Store中的所有内容、Creative Cloud、Tor浏览器、破解或逆向工程工具等。这意味着，苹果可以知道你何时在家，何时在工作，甚至在朋友家的WiFi上打开了Premiere......

　　这些现象大家似乎司空见惯，但问题是：

　　这些OCSP请求是未加密传输，也就是说网络上的每个人都能看到，包括你的网络服务提供商，以及所有窃听者。

　　这些请求将被转到另一家公司Akamai经营的第三方CDN。

　　棱镜计划让美国联邦警察和军方随时随地不受限制地访问这些数据，而无需发出任何指令。

　　更糟的是，OCSP通常使用HTTP。如果使用HTTPS通过OCSP检查证书，则还需要使用OCSP检查HTTPS连接的证书。这意味着打开另一个HTTPS连接，依此类推。

　　当然，尽管OCSP不要求加密，但确实要求响应由服务器签名。这仍然不能解决我们最初担心的问题，即如果在网络上装上流量分析器，任何人都可以“窃听”你打开的每个应用程序，以及打开应用程序的时间。

　　真的假的?

　　这些要是真的，那真是太可怕了!

　　问题是，Jeffrey Paul在文章中提到的macOS涉及的安全问题是真实的吗?对此，有人提出了疑问，比如这位米兰理工大学的硕士研究生Jacopo Jannone，他在一篇博客中从技术的角度进行了详细的分析。

　　这些疑问包括：OCSP是关于检查证书的，那跟发送运行的应用程序的哈希值有什么关系?macOS每次启动时是否真的计算每个可执行文件的哈希值?那超大的文件呢?这个过程要花费大量时间，可能没有人注意到吗?也许哈希仅计算一次(例如，第一次运行该应用程序时)，并将其存储在某个位置，但Jacopo Jannone表示，Jeffrey Paul的说法需要进一步的研究。

　　为了证明自己的质疑，他贴出了自己求证的过程(以下为译文)：

　　捕获OCSP请求就像设置HTTP代理或启动Wireshark一样容易。没有HTTPS意味着没有加密，没有证书固定，没有任何问题。我在Firefox时捕获了以下请求。

　　GET /ocsp-devid01/ME4wTKADAgEAMEUwQzBBMAkGBSsOAwIaBQAEFDOB0e%2FbaLCFIU0u76%2BMSmlkPCpsBBRXF%2B2iz9x8mKEQ4Py%2Bhy0s8uMXVAIIBseUIWx6qTA%3D HTTP/1.1Host: ocsp.apple.comAccept: */*User-Agent: com.apple.trustd/2.0Accept-Language: it-itAccept-Encoding: gzip, deflateConnection: keep-alive

　　补充一点，在关闭Firefox并再次打开之后，没有发生任何请求。这是合理的，这表明并没有在每次启动时都进行了证书检查，而是仅在一段时间内未执行证书检查之后才执行。

　　这个请求是一个非常简单的GET，其中包含有效负载作为base64编码的字符串。实际的二进制数据可以很容易地转储到文件中：

　　echo 'ME4wTKADAgEAMEUwQzBBMAkGBSsOAwIaBQAEFDOB0e/baLCFIU0u76+MSmlkPCpsBBRXF+2iz9x8mKEQ4Py+hy0s8uMXVAIIBseUIWx6qTA=' | base64 --decode > output.bin

　　我们获得了一个80字节长的有效负载，看起来根本就不像一个哈希。事实上还真不是。我们可以使用OpenSSL从二进制文件中提取可读信息。

　　openssl ocsp -text -reqin output.binOCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 3381D1EFDB68B085214D2EEFAF8C4A69643C2A6C Issuer Key Hash: 5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754 Serial Number: 06C794216C7AA930

　　显然，trustdmacOS上的服务不会发送你启动的应用程序的哈希值。相反，它只是发送有关某些证书的信息。

　　但这不能解决问题，对吗?如果每个应用程序都有唯一的证书，那么仍然有可能创建一个将每个序列号与相应应用程序相关联的表，因此仍然存在隐私问题。我们来看一下是不是这样。

　　开发者认证…

　　首先，我想确定某个信息来自哪个证书。我使用Apple的codesign实用程序从Firefox应用程序中提取证书，以查找匹配的数据。

　　codesign -d --extract-certificates /Applications/Firefox.app

　　此命令创建了几个名称为codesign0，codesign1等的文件。第一个是叶证书，而其他文件则属于根目录的证书链。codesign0应该就是我们要找的东西，我们可以再次用OpenSSL提取有关信息。

　　openssl x509 -inform der -in codesign0 -textCertificate: Data: Version: 3 (0x2) Serial Number: 488521955867797808 (0x6c794216c7aa930) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Validity Not Before: May 8 19:08:58 2017 GMT Not After : May 9 19:08:58 2022 GMT Subject: UID=43AQ936H96, CN=Developer ID Application: Mozilla Corporation (43AQ936H96), OU=43AQ936H96, O=Mozilla Corporation, C=US ...

　　检查一下我们获得的序列号(0x6c794216c7aa930)，并将其与OCSP请求的有效负载进行比较。结果证明，OCSP请求实际上发出了有关应用程序开发者证书的信息。

　　一般性

　　“所以呢?” 你可能会问。嗯，并非每个应用程序都有唯一的开发人员证书。耳听为虚，我们可以通过检查来自Mozilla的其他应用程序的证书来快速验证这一点，比如Thunderbird。

　　codesign -d --extract-certificates /Applications/Thunderbird.appopenssl x509 -inform der -in codesign0 -textCertificate: Data: Version: 3 (0x2) Serial Number: 488521955867797808 (0x6c794216c7aa930) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Validity Not Before: May 8 19:08:58 2017 GMT Not After : May 9 19:08:58 2022 GMT Subject: UID=43AQ936H96, CN=Developer ID Application: Mozilla Corporation (43AQ936H96), OU=43AQ936H96, O=Mozilla Corporation, C=US ...

　　这与用于Firefox的证书完全相同(当然是!)。因此，Jeffrey Paul的分析不够准确，至少对于涉及这些部分的问题。

　　操作系统在运行时会向Apple发送所运行的每个程序的哈希(唯一标识符)。

　　[IP地址]允许具有以下标题的表：日期，时间，计算机，ISP，城市，州，应用程序哈希

　　[这意味着Apple知道]你在哪里打开了哪些应用，以及打开频率。他们知道你何时在你朋友家的Wi-Fi上打开Premiere，并且知道你何时在前往另一座城市的旅馆中打开Tor浏览器。

　　macOS实际上确实发出了有关这些应用程序的开发人员证书的一些不透明信息，这在隐私角度上是非常重要的区别。

　　关于公证

　　有些概念可能是造成这种误解的根源。实际上，在一种情况下，macOS的确可以向苹果发送可执行文件的哈希值，即应用程序首次启动时，Gatekeeper会检查Apple的服务器上是否有公证单。

　　这其实与OCSP无关，只在特定的情况下才会发生，而且检查是通过位于api.apple-cloudkit.com的安全(HTTPS)端点。在此过程中，用户会看到一个带有进度栏的弹出窗口。

　　关于阻止OCSP

　　正如你可能已经在Apple的OCSP响应器中断期间了解到的那样，你可以通过几种方式阻止OCSP请求，其中最受欢迎的是Little Snitch ，并编辑/etc/hosts文件。就个人而言，我不建议这样做，因为它会使重要的安全功能无法正常工作。

　　现在，了解了这些事实，如果你认为此功能对你的隐私造成的威胁大于在系统上运行潜在的未被检测到的恶意软件，可以继续用这种方法。否则，不要冒险。

　　如果你用的是macOS Big Sur，则阻止OCSP可能不那么容易。请记住，普通用户通常无法完全理解和评估禁用这种复杂而微妙的安全功能，会对自己的计算机产生怎样的影响。

　　观点总结

　　不，macOS不会在每次运行应用程序时向Apple发送哈希值。

　　注意，macOS可能会传送有关你运行的应用程序的开发者证书的一些不透明信息。此信息以明文形式发送到你的网络上。

　　你也许不应该用Little Snitch，或在你的主机文件中阻止ocsp.apple.com。

　　结尾

　　既然苹果已经公布了应对此次bug的解决方案，网友提出的上述方法似乎也没有了使用的必要。虽然目前为止，还没有用户反馈因此遭受重大实际损失，但暴露出的安全隐私问题，以及网友们对macOS安全技术的讨论和关注，再次给人们敲响了警钟。

　　也许Jeffrey Paul的说法有点夸张，但自诩安全的苹果在隐私上也并非铜板一块。正如斯托曼和多克托洛所预言，平日里我们在安全隐私问题上被温水煮青蛙，如今这水已经沸腾起来了。

文章来源:CSDN