整理 | 夕颜
php
出品 | CSDN（ID:CSDNnews）
nginx
近日，苹果在发布会上推出了数款专用芯片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 也发生了缓慢、中断和不正常的现象。api
不久以后，一些Mac用户还发现，当尝试用trustd（一个负责与Apple的服务器进行核对，以确认应用程序是否通过认证的MacOS进程）与ocsp.apple.com联系时，发生反复失败的状况。这致使App启动时发生系统性大规模的速度下降。浏览器
有用户反馈，打开控制台并进行过滤以查找错误的用户，遇到了许多与Trusted相关的连续错误，以下图所示。
缓存
trustd负责核实Developer ID证书的状态，而不是公证。但这不是重点。关键是，当Apple的CDN掉线时，Apple的OCSP服务器中止响应，而且当这种状况发生时，许多联网的Mac就会中止工做。安全
trustd进程只是为了在没有联网状况下继续运行，并不是是为了处理trustd能够链接Apple的OCSP服务器，但服务器没有响应的状况。bash
事故发生时，不少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: sha1Issuer Name Hash: 3381D1EFDB68B085214D2EEFAF8C4A69643C2A6CIssuer Key Hash: 5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754Serial 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: sha256WithRSAEncryptionIssuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=USValidityNot Before: May 8 19:08:58 2017 GMTNot After : May 9 19:08:58 2022 GMTSubject: 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: sha256WithRSAEncryptionIssuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=USValidityNot Before: May 8 19:08:58 2017 GMTNot After : May 9 19:08:58 2022 GMTSubject: 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 高校俱乐部 ☞腾讯回应发布虚假广告被罚20万；苹果客服回应iPhone 12屏幕发绿；Chrome 87 正式版发布|极客头条 ☞赠书 | 图像分类问题建模方案探索实践
☞大神们都是如何在时间序列中进行特征提取的？看完就懂了！ ☞Value DeFi遭黑客攻击始末，闪电贷此次又带走了700万美圆
点分享点点赞点在看