原文地址：www.security-embedded.com/blog/2020/1…
原文作者：www.security-embedded.com/blog
发布时间：2020年11月14日
2020年11月12日，苹果发布了macOS Big Sur。在发布上线后的几个小时里，苹果基础设施中的某个地方，一个在线证书状态协议（OCSP）应答器痛苦地大喊大叫，跪在地上求饶，因为负载的增加超出了它所能承受的范围。OCSP响应器减速，是现代公钥基础设施(PKI)的一个重要方面，这使得PKI的客户端很难验证身份文件的有效性。这些被称为X.509证书的文件被附加到用户在Mac上启动的每一个经过验证的应用程序上。随之而来的是混乱，在问题被清理后，许多问题仍然存在于这次失败的影响。但首先，让我们来看看在最基本的层面上，验证一个应用程序包所涉及的机制。
什么是X.509？
X.509是一个经过批准的ITU规范，它定义了（除其他外）一个传递实体间信任关系的文档的标准表示，即所谓的证书。证书可以被认为是政策文件。任何X.509证书包括
- 公钥；
- 说明证书是为谁签发的；
- 权力机构允许证书持有者执行什么行动
- 证书首次生效的日期；
- 证书到期的日期；
- 关于如何检查证书是否已被撤销的元数据（可选，但强烈建议）；
- 签发证书的机构，以及
- 所有这些元数据的签名，来自权威机构。
通过检索权威证书，可以验证所发证书的完整性。事实上，大多数权威证书都是由更高的权威机构颁发的。通过一路验证，直到根实体证书（"自签 "的最高级别权威机构），可以对最终实体证书的出处获得高度的信任。通常情况下，权威机构向最终实体或任何中间实体颁发证书必须满足一定的政策要求。证书可以被看作是证明有关当局进行了适当的检查以确保所有这些条件得到满足的一种体现。如果你没有通过这些检查，当局就不应该给你颁发证书!
创建这些文件的仪式，如何解释文件，如何代表商业信任决策的层次，都被编码在证书链中。证书链是一个强大的概念：它们可以用来验证一个权威机构，谁生成了一个公钥，谁验证它是按照一定的标准完成的。通过指定只接受源自某些根机构的证书链，将公钥的范围缩小到只有你信任的密钥，你可以制定一个政策，拒绝任何由不同机构颁发的公钥（从而拒绝任何证书）。
困难的部分：撤销
但是，如果在证书签发之后、证书到期之前，出了问题怎么办？也许权威机构认定证书颁发给的实体犯了一些渎职行为，于是撤销了他们的证书。有時候，證書的私密金鑰被偷了，那麼證書所代表的一方是誰的斷言就不再是真實的，因為擁有被偷的金鑰的實體可以冒充合法的原方。证书被撤销的原因有很多。
X.509的一个奇妙的设计属性是，你应该可以离线执行X.509证书链验证。只要你对当前的日期是什么以及你信任的根实体有一个准确的概念，那么对于一方来说，验证一个证书链是（相对）容易的。离线验证赋予了系统很大的弹性。但是这个撤销问题仍然是一个挑战--对于某些系统来说，你需要能够向签发证书的权威机构进行回访，并询问 "嘿，你做的这个断言还有效吗？"
为了解决这个问题，目前常用的机制有三种。首先，大多数权威机构都会发布证书撤销清单（CRL）。这个由签发机构签署的列表可以定期从证书元数据中指定的位置下载（比如说每天下载一次）。当执行证书验证时，本地下载的CRL副本将提供证书是否已被撤销的指示。但这些CRL可能会变得相当大，而且必须等待CRL被刷新才能生效，这对某些应用来说是有风险的。CRL对于某些用例来说是可行的，但存储和更新频率的权衡是很重要的。
输入OCSP。当权威机构提供OCSP响应者时，响应者的URL也会被编码在证书中。证书验证者可以调用OCSP响应者，并提供要验证的证书的序列号。OCSP响应者会根据其数据库中的废止证书进行检查。然后，OCSP响应者会对查询作出简单的 "有效 "或 "已撤销 "的响应，然后呼叫方可以决定如何处理这些信息。当然，这意味着OCSP响应者可以记录下每一次的查询，并建立一个非常有用的纸质线索来帮助监控用户行为。这种风险，以及系统弹性的挑战，导致了寻找一个中间地带。
最后一种模式是调用OCSP响应者的变体。OCSP响应者可以向证书持有者发出一个短暂的、经过加密签名的文件。该文件与证书 "订在一起"，并发送给验证方。只要时间戳吻合，接收方就可以认为（在一定的风险范围内）证书仍然有效，按照发证机关的规定。当然，这种方法只适用于某些用例（通常是面向连接的用法），但它确实能使证书验证方匿名。
苹果选择了第二种撤销模式进行应用证书验证。这种模式有其好处--可以实时进行撤销。因此，如果苹果发现他们颁发给某个应用的证书其实是恶意软件，他们可以迅速撤销这个证书，并阻止恶意软件的运行，甚至在它已经安装在自己的机器上。这确实让苹果掌握了很多政策控制权。这时你就必须做出商业决定，是否相信苹果是仁者见仁智者见智了。
X.509和认证签名的应用程序
签名的申请是证书验证中一个有趣的角落案例。证书的有效期在一定的日期范围内。此外，应用程序不涉及（至少在启动时）服务器和客户端之间的任何形式的交换，客户端可以代表你执行OCSP查询。这限制了我们的选择。
第一个问题比人们想象的要细微得多。一个在特定时间点上签署的应用程序，是否应该只能在为签署该应用程序而签发的证书的有效期开始/结束日期之间启动？也许不应该--这给应用程序的有效期设置了一个人为的界限，如果这是你花了很多钱购买的应用程序，这可能会让人感到沮丧。实现细节可能会有所不同，但有一个受信任的时间戳服务器的概念，其中带有nonce的时间戳由一个受信任的权威机构签署。通过将受信任的时间戳集成到由应用程序启动器加密验证的属性捆绑中，我们可以将这个问题减少到只需要验证应用程序签名证书在捆绑签署时是有效的。因此，当前的日历日期与确定这个有效性无关，而是要使用已经捆绑到签署的应用中的日期。
第二个问题限制了你处理撤销的选择。在某些情况下，CRL可能是有用的--例如，如果大量的证书要被撤销，那么CRL就会有用。然而，除了这些撤销列表的可扩展性和大小之外，这种方法还存在一些问题。其中一个操作上的顾虑是，你可能会泄露哪些证书已经被撤销的信息，或者提供撤销过程的信息。这可能会被不法行为者利用，来玩弄证书颁发过程，或者至少让哪些证书被撤销以及何时被撤销变得更加明显，这样恶意软件开发者就可以更深入地了解这个过程，让他们在 "游戏系统 "中占据优势。
苹果选择用OCSP响应器来解决这个问题。因此，在每次启动应用程序时（也许在某个窗口外，OCSP响应可以被缓存--我没有研究过这个细节），macOS会尽职尽责地根据OCSP响应器检查签名者使用的证书是否仍然有效。当然，如果macOS无法联系到OCSP响应者，它就会继续愉快地启动一个应用程序。毕竟，电脑也需要离线工作。
隐私影响与可用性
正如我们以前所讨论的那样，OCSP响应者肯定会产生日志。这些日志可以包含用户要求检查的证书序列号，以及请求者的IP地址。苹果肯定有一个数据库，可以将序列号映射到实际的X.509证书上，然后很可能被用来识别这个证书是用来签署什么应用的。关于请求的元数据可能会被映射到你是谁（通过AppleID的力量，也许），证书的属性可能会被绑定到你的应用商店购买（或没有购买）。理论上讲，这可以用来打击盗版、私人软件分发和其他设备的自由使用。
但这里我们要考虑到用户的问题。我日复一日地深陷在系统安全问题中。所有这些我们与之交互的系统已经变得更加复杂，超过了大多数人（包括我自己）所能维持的心理模型。恶意软件藏在比我有创意的脑细胞能想到的更多的地方，我运行的每一个可执行包都会让我怀疑我可能会把王国的钥匙交给谁，尤其是如果没有办法把这个包和构建它的原始开发者联系起来。在我看来，应用签名其实是一件非常好的事情。如果说，它能让我相信，在开发者构建包和我安装包之间，包没有被篡改过。
我一直主张，对于应用签名这样的基础安全功能，不要选择退出。即使有选择退出，开发者也必须尽可能地让用户不愉快地选择退出。为什么这样做呢？大多数用户没有能力评估选择退出应用签名这样的安全流程的影响。一个写着 "禁用所有代码签名检查 "的空白开关，即使是暂时的，很多用户也很难理解其中的影响。而一旦设置了这个开关，用户（他已经很难记住密码了）如何记住这个设置已经被改变了呢？如何衡量这对系统完整性的影响？用户如何知道一个启用了控制的系统和一个没有启用控制的系统之间的区别？用户如何解释这对他们的计算机有什么影响？
更新：有一些人指出，苹果提供了在每个应用程序启动的基础上暂时禁用应用程序签名验证的功能。我并不喜欢这些功能：这使得用户更容易被欺骗，对自己的电脑进行不安全的修改。同时，这也使得应用黑名单和Gatekeeper启用的其他功能难以受益。
谷歌在Pixelbook的启动过程中采取了一种有趣的方法。当你启用启动来自谷歌以外来源的签名镜像时，启动时一个非常恼人的弹出窗口（如果记得的话，还有完整的声音效果）会提醒你，你正在启动不受信任的代码。这对开发者来说是有效的，但大多数用户会对这个消息的含义感到困惑。在网上搜索这条消息的答案时，有人认为你应该完全忽略这条消息。这可不是什么好事。
有人可能会说，苹果在这种情况下迎合了最低的共同点。这有一定的道理--你不想对你的用户发起战争，并认为他们是愚蠢的。但如果作为 "信息安全专家 "的人连各种控制措施的真正含义都无法告诉你（由于这些系统的巨大复杂性），你的普通用户又怎么能做出这些决定呢？
最后，还有一个开源的说法--如果我有代码，构建代码，代码里就什么都藏不住。这是一个谬论，由于开源社区的有效营销，人们相信了这个谬论。今天的软件系统是如此复杂，即使是最精心策划的代码库中也潜藏着微妙的问题。你自己构建并运行的Chrome浏览器是否会比你从谷歌下载的、由苹果公司共同签署的Chrome浏览器更安全或更不容易被入侵呢？绝对不会（事实上，我想说的是另一个方向，但这与我们的讨论无关），但如果发现软件包中嵌入了一些恶意软件，那么由苹果共同签署的Chrome构建体可能会被撤销。这是一个有趣的控制，对用户有很大的好处。
狗哨子
隐私保护小组在这个问题上动员了起来 - 事实上，一篇博客文章因为用 "你不再是你电脑的主人！"的狗哨声谴责这种系统而受到了很多关注。有人从Epic Megagames的情况来看，《Fortnite》已经被从iOS（和Android）的App Store中撤下，以此证明这些系统有可能被滥用。说实话，他们的观点是有道理的--在一个狭窄的话语宇宙中。
归根结底是信任的争论--你是否相信苹果公司，以他们的最大利益行事，也足以与你的最大利益保持一致？还是你相信他们是一个恶意的实体？对于个人来说，要想维持苹果公司那样的值得信赖或不值得信赖的当事人名单是不可行的。无论你是谁，你最终都会把这个工作外包给某个人--大多数用户都有能力运行一个安全程序，监控恶意应用（同样适用于大多数企业）。这让人回想起经典的杀毒软件价值主张--传统的杀毒软件之所以有价值，是因为必须有人在某个地方先遇到病毒，然后将其报告给杀毒软件供应商，然后由他们制作签名。但自己复制这种做法是不可行的：你需要众包和广泛的网络来提前获得这些报告，以做出反应。或者你干脆从别人那里购买这种服务。
也许更多的透明度将有助于缓解人们对滥用其数据的担忧。让一个可审计的第三方运行OCSP响应者进行应用证书检查，将缓解人们对苹果滥用这些数据的担忧。也许苹果可以做一些调整来提高透明度，而不放松他们提供的平台安全模式。有谁愿意对这个假设的OCSP响应者进行审计？
在早晨的严酷光线下
在OCSP应答器故障之后，macOS Big Sur版本的发布也尘埃落定，有很多人合理地问，他们是否可以相信苹果公司在决定什么应用程序应该或不应该在他们的Mac上运行的圈子里。我的观点是 - 谁比苹果更好？
微软也是如此--Windows已经取得了惊人的进步，超越了其他操作系统所提供的控制，为用户提供了大量的简便性，同时专注于验证谁编译了运行在用户PC上的代码。这个过程中的信任是至关重要的（因此Stuxnet驱动签名证书私钥被盗事件才会造成如此巨大的打击），最终选择加入这种信任模式是一个商业（至少是个人）决定。
虽然我要听起来像一个苹果的辩护人，但我认为隐私的争论是牵强附会的。即使我们把它们带到极端的结论，苹果允许用户禁用他们提供的所有控制措施，我们也会弊大于利。苹果当然有机会滥用他们所能接触到的数据（天啊，他们确实有很多用户的数据），但我又想到Reddit、Facebook、Google和PornHub等公司所拥有的普通用户的数据，就会问自己，谁最有能力损害一个人的生活？
Reddit知道你在搜索什么，你访问了哪些subreddit论坛，甚至在那个隐身窗口里也知道。我也确信，PornHub的每一个查询都有IP地址和日期的索引......如果你觉得很难映射到某个人身上，我有个坏消息要告诉你，来自长岛的Steve。
