2020年11月13日，一个普通的不能再普通的早晨，周五让人有点期待，美妙的周末在殷殷招手，或许你已经知道苹果推送了最新的 macOS Big Sur，或许你不知道。日常地打开 Mac，日常地点击熟悉的生产力软件，搓搓手，准备开始一天的工(mō)作(yú)。超出意料时长的软件图标跳跃以及无法打开的提示让你感受到一丝丝的不安定，试了几个常用的软件，你赫然发现，第三方软件打不开了！
实际上，你并不是孤例，国内外大量的 Mac 用户都遭遇了相同的问题，很快，问题就被排查出来了，罪魁祸首是苹果的验证应用可信的公证服务器 OCSP 服务！与往常不同，OCSP 验证服务器并没有中断，而是响应缓慢，系统不断的发送验证请求，最终超时亦或者响应失败断开，类似于办理业务时，窗口依然开放，但是工作人员不在，最终事情没有办理成功，但是难得的时间没有了。
苹果很快就解决了这个问题，但是一场小小的隐私风暴，却悄然形成，呈愈演愈烈之势。
让我们一点一点来。
关于OCSP (Online Certificate Status Protocol)，先摘抄一段维基百科的定义：
在线证书状态协议（Online Certificate Status Protocol，缩写：OCSP）是一个用于获取X.509数字证书撤销状态的网际协议，在RFC 6960中定义，作为证书吊销列表（CRL）的替代品解决了在公开密钥基础建设（PKI）中使用证书吊销列表而带来的多个问题。协议数据传输过程中使用ASN.1编码，并通常建立在HTTP协议上，此消息类型分为“请求消息”和“响应消息”，因此致OCSP服务器被称为“OCSP响应端”。
正如该协议的名称所示，它的作用是用来验证当前证书状态的一种网络协议，作为 CRL 的替代品，它可以在不下载和扫描大型证书撤销列表的情况下，验证证书的有效性，提升网络效率，改进用户体验。
上文中，我们多次谈到了证书 (Certificate Authority, CA, 数字证书)，因为涉及到很多网络安全的内容，为了避免繁杂的技术描述，我仅做简单的解释，首先看一下一个合格的 CA 应该包含的内容：
CA 保证了 CA中的公钥的确为该证书所有者（Subject）所持有。在我们日常生活中，接触到CA最多的可能是HTTPS协议，通过证书校验，客户端可以最大程度上保证用户接收到信息是无篡改的，进而保证了用户信息的安全。
我们也可以看到 CA 也是有有效期的，其目的是为了优化吊销列表，当网站的私钥发生丢失，网站可以向 CA 的颁发机构申请将 CA 吊销，进而保护用户的安全，如果不设置有效期，随着吊销列表的增加，用户的浏览体验也会因为验证时间过长而大大下降，因此，过期的 CA可以直接从列表中剔除掉，因为其本身也不会受到客户端的信任。
正如前文所解释的，OCSP 的主要作用就是验证 CA 的有效性，在 macOS 中，苹果用 OCSP验证开发者证书的有效性。
OCSP 可以用于证书的验证，保护用户的信息安全，但是 OCSP 的设计自身却出了问题----OCSP 是未加密的！为什么不加密，因为加密之后的 OCSP 信息的 证书也需要验证，否则也是不可信的，这便是一个鸡生蛋的问题。OCSP的安全性不佳作为原因之一，Chrome 已经默认不再进行 OCSP（但可以手动打开）。
正是这个问题，导致了如下的两个核心争议点：
听着就挺可怕！
隐私问题
隐私，是苹果在新时代立的最大的一个 Flag，不管是广告，WWDC 或者任何一场发布会，每一个系统，每一台设备，苹果都在不遗余力地宣传对于用户隐私的重视与保护，然而，在OCSP 上，苹果却遭遇了自 FBI 辅助调查事件以来，最有趣的一次隐私争议，苹果有罪论主要开炮的点有：
自 Mac 引入 T2 芯片以来，Mac 用户某种程度上已经失去了对于硬件的控制权，M1 芯片的驱动的 Mac 更是集大成者，高度集成的硬件以及安全芯片的加持，使得大部分的普通用户已经无法对硬件做任何的修改。本次 OCSP 故障，更是加剧了在苹果的 OCSP 校验机制下，苹果虽然不能控制用户安装了什么 app，但是可以禁止 app 启动的担忧。如果这样的事情发生的话，在苹果的生态中，用户在软硬件层面完全失去了设备控制权。
据 The Verge 报道，苹果已经证实，在对新款 Mac 的主板、Touch ID 传感器等零部件进行维修更换时，T2 芯片会对未授权的零部件进行限制。
当争议点列出之后，双方站位明确，观点集中且对立：
作为普通的用户，技术之争大多时候只能作为看客，而对于风险，确实实实在在落在我们的身上，我们更关心的是上述的争议的事实究竟是什么？
应用启动时的确会进行 OCSP 校验，但是 OCSP 机制存在缓存机制，各类事件都会触发 OCSP，并不是每一次的启动都会进行校验，但是苹果确实可以获取到用户的 Mac 上安装的 app 信息，毕竟，安装完成的软件总会要打开的。基于这个前提并得到苹果收集并分析用户隐私却并不是合理的，但是遗憾的是，这也是一个难以证伪的一个问题，毕竟我们都不是苹果内部人士，不可能知道苹果是不是真的做了这件事。
可是，不能证伪也并不能证明苹果真的做了这件事，但是如果我们可以简单分析一下必要性，当我们使用第一次进入系统的时候，苹果会请求用户分享 app 的使用信息以提升用户的使用体验，这个选项是默认同意的，我认为大部分用户一般不会费心关掉这部分内容，在勾选的情况下，用户的 app 使用信息本身就会传输给苹果，公然收集明文传输的内容并与用户建立一对一的关系，一旦被发现，一向宣传隐私重要性的苹果的商业信誉将会面临极大的挑战，甚至说崩塌也不为过，如此巨大的商业风险，一个主要收入来源依旧是硬件的商业公司，会铤而走险吗？
当然，请注意，这仅仅代表我个人的观点。
也有开发者指出如果苹果需要将用户 IP 与用户列表相对应，采用 iCloud 的数据要比 OCSP 的数据更加精准且高效。
关于隐私被泄漏的风险，这个的确是实打实的存在的，毕竟 OCSP 是明文传输内容的，许多的文章都尝试抓取 OCSP 信息，并解析到了开发者的证书信息。这个风险是由苹果采用了旧时的标准而带给用户的。
11月16日北京时间夜间，苹果更新了在线文档 Safely open apps on your Mac：
In addition, over the the next year we will introduce several changes to our security checks:
A new encrypted protocol for Developer ID certificate revocation checks
Strong protections against server failure
A new preference for users to opt out of these security protections
此外，在接下来的一年里，我们将对我们的安全检查进行一些改变：
一个新的用于开发者ID证书撤销检查的加密协议
强大的保护措施，防止服务器故障
用户可以选择不使用这些安全保护措施
可以看到苹果承认了该风险的存在，并作出在明年会有更好的应对方案的承诺，但是目前仍然没有解决方法，同时，即使明年推出了新的验证方式，如果是系统级的更新，未获得升级的旧设备依然暴露在风险之中，如何兼容旧体系的情况下提升安全性，苹果还有很多的路要走。
关于设备控制权的担忧也并非是空穴来风，我个人对于一个无法自行升级的电脑设备也挺无奈的，苹果会不会在未来积极配合法律法规禁止某些 app 的启动仍未可知，不要忘记苹果为符合各国的法律法规，会在iOS 的App Store 毫不犹豫下架相关 app，当然了，这份风险不是 macOS 用户独享的，Windows也有类似的 Smart Screen 机制去阻止 app 的运行，但是，截止目前来看，这些机制设计的初衷是防止恶意程序而并非正常的程序，因此，对于普通用户来说，目前似乎并没有什么好的解决的办法，只能说暂时还不需要担心太多。
作为一个商业公司，苹果毕竟还是会收到法律以及媒体的监管与监督，要放开手脚执行这样的一个政策，并不是一件容易的事情。
在苹果目前的设计中，如果 OCSP 服务失败，用户依然可以打开应用程序，这也是13日故障发生时，通过断网之类的方法便可以打开第三方软件，一些反应快速的应用程序已经宣布在新版本中支持屏蔽 OCSP 服务。
对于 OCSP 的争议，每个人都有自己的看法，你可以认为苹果是 Evil（恶魔），控制用户，扯起虎皮做大旗，这件事正好暴露了苹果的邪恶之处，那么你可以放弃苹果设备，投向Windows/Linux的怀抱；你也可以觉得服务修好了就好了，争议什么的太无聊，事不关己，不关心，不关注；也可以认为苹果有错，应该接受批评，但是犯错是正常的，改正了还是好同志。
数字时代，保护好自己的隐私是一件不容易的事情，越来越多的数据泄露事件越发证明了没有什么系统是坚不可摧的，任何一个环节的出错都有可能造成大规模的数据泄露事故。虽然苹果不断的强调保护用户的隐私，但追根究底苹果依然是一个商业公司，它所作出的选择一定是在公司利益与公共利益之间达到某种可以接受的平衡的基础上的，因此并不需要神话它，它也会作出错误的选择，它也会坑用户，它也会在自己坚持的原则面前寸步不让。
我并不反对争议，这说明了公司能够接受到来自用户与其他机构的监督，并且能越做越好。至少，一个敢于将保护用户隐私作为公共宣传方案的公司比一个热衷于逃避风险，漠视用户，肆意收集用户隐私的公司更让人放心一些。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。