应用程序信任很难，但苹果做得很好

2020年11月12日，苹果发布MacOS Big Sur。在发布后的几个小时里，在苹果基础设施的某个地方，一个在线证书状态协议(OCSP)的响应者痛苦地喊叫着，跪在地上，乞求宽恕，因为负荷增加到了它无法承受的地步。OCSP响应器的速度变慢是现代公钥基础设施(PKI)的一个重要方面，这使得PKI的客户很难验证身份证件的有效性。这些被称为X.509证书的文档被附加到用户在Mac上启动的每个经过验证的应用程序上。混乱随之而来，在问题被清理后，关于这一失败的影响仍然存在许多问题。但首先，让我们看看在最基本的层面上认证应用程序包所涉及的机制。

X.509是经批准的ITU规范，它定义了传递实体之间信任关系(称为证书)的文档的标准表示形式(以及其他内容)。证书可以被认为是策略文档。任何X.509证书都包含。

有关如何检查证书是否已被吊销的元数据(可选，但强烈建议)，

通过检索授权证书，可以验证颁发的证书的完整性。事实上，大多数权威证书都是由更高级别的机构颁发的。通过一直验证到根实体证书(自签名的最高级别权威机构)，可以高度信任最终实体证书的出处。通常，授权机构向终端实体或任何中间实体颁发证书时，必须满足一组特定的策略要求。证书可以被视为有关当局进行了适当检查以确保满足所有这些条件的证明的具体体现。如果你没有通过这些检查，权威机构就不应该给你颁发证书！

创建这些文档的仪式、如何解释文档、如何表示业务信任决策的层次结构都编码在证书链中。证书链是强大的概念：它们可用于验证生成公钥的机构，以及验证其是否符合特定标准的机构。通过将公钥的范围缩小到只信任您信任的密钥(只指定您将接受源自的某些根授权机构)，您可以制定一项策略，拒绝由其他授权机构颁发的任何公钥(以及任何证书)。

但是，如果在证书颁发日期之后、证书过期日期之前出现问题，该怎么办？也许当局认为颁发证书的实体犯了一些不法行为，并吊销了他们的证书。有时证书的私钥会被窃取，因此证书所代表的关于该方是谁的断言不再正确，因为具有被盗密钥的实体可能会冒充合法的原始方。证书可能被吊销的原因有很多。

X.509奇妙的设计属性之一是您应该能够离线执行X.509证书链验证。只要你对当前日期和你信任的根实体有一个准确的概念，一方就可以(相对)容易地验证证书链。离线验证给系统带来了极大的弹性，这是非常棒的。但这个吊销问题仍然是一个挑战--你需要能够向颁发证书的权威机构核实，并询问一下，嘿，你的断言仍然有效吗？

为了解决这个问题，目前有三种常见的机制在使用。首先，大多数机构发布证书吊销列表(CRL)。该列表由颁发机构签署，可以从证书元数据中指定的位置(例如每天)定期下载。在执行证书验证时，本地下载的CRL副本将提供证书是否已被吊销的指示。不过，这些CRL可能会变得相当大，并且必须等待CRL刷新才能使吊销生效，这对某些应用程序来说可能是有风险的。CRL适用于某些用例，但存储和更新频率的权衡非常重要。

输入OCSP。当授权机构提供OCSP响应器时，该响应器的URL也会编码到证书中。证书验证者可以使用要验证的证书的序列号呼叫OCSP响应者。OCSP响应器对照其吊销证书数据库进行检查。然后，OCSP应答器将用一个简单的、有效的或已撤销的信息来响应该查询，然后呼叫方可以决定如何处理该信息。？当然，这意味着OCSP响应者可以记录每一个查询，并建立一个非常有用的书面记录来帮助监控用户行为。这种风险，加上系统性的弹性挑战，促使人们寻找中间立场。

最后一种模式是调用OCSP应答器的变体。OCSP响应者可以向证书持有者发布使用密码签名的短期文档。这份文件与证书一起被装订起来，并被发送给验证方。只要时间戳匹配，根据颁发机构，接收者就可以假定(在一定的风险范围内)证书仍然有效。当然，这种方法只适用于某些用例(通常是面向连接的用法)，但它确实将证书验证方匿名。

苹果选择了第二种吊销模式进行APP证书验证。这种模式有它的好处--撤销可以实时执行。因此，如果苹果发现他们颁发证书的应用程序实际上是恶意软件，他们可以迅速撤销该证书，并阻止恶意软件运行，即使是在它已经安装了自己的机器上也是如此。这确实将大量政策控制权交到了苹果手中。这是你必须做出商业决定的地方，你是否相信苹果是仁慈的。

签名的应用程序是证书验证中一个有趣的角落案例。证书在一定日期范围内有效。此外，应用程序不涉及(至少在启动时)可以代表您执行OCSP查找的服务器和客户端之间的任何类型的交换。这限制了我们的选择。

第一个问题比人们想象的要微妙得多。签署了特定时间点的应用程序是否只能在为签署该应用程序而签发的证书的有效期开始/结束日期之间启动？可能不是--这给应用程序设置了一个有效的人工视界，如果这是一个你花了很多钱买的应用程序，这可能会令人沮丧。实现细节可能会有所不同，但存在可信时间戳服务器的概念，在该服务器中，带有现时值的时间戳由可信机构签名。通过将可信的时间戳集成到由应用程序启动器加密验证的属性包中，我们可以将这个问题减少到只需要验证应用程序签名证书在包签名时是有效的。因此，当前日历日期与确定有效性无关，而是要使用已绑定到签名应用程序中的日期。

第二个问题限制了您处理吊销的选择。CRL在某些情况下可能很有用-例如，如果要吊销大量证书。然而，除了这些撤销列表的可伸缩性和大小之外，这种方法还存在一些问题。操作上的一个顾虑是，您可能会泄露有关哪些证书已被吊销的信息，或者提供有关吊销过程的详细信息。不法分子可能会利用这一点来玩弄证书颁发过程，或者至少让人们更清楚地知道哪些证书已经被吊销，以及何时被吊销，这样恶意软件开发者就可以更深入地了解这一过程，让他们在玩弄系统时占据优势。

苹果选择用OCSP响应器来解决这个问题。因此，每次启动应用程序时(可能是在某个可以缓存OCSP响应的窗口之外--我还没有查看这一细节)，MacOS会按照OCSP响应者的要求，尽职尽责地检查签名者使用的证书是否仍然有效。当然，如果MacOS不能联系到OCSP响应者，它就会顺其自然地推出一款应用程序。毕竟，计算机也需要离线工作。

正如我们之前讨论的，OCSP响应器当然可以生成日志。这些日志可能包含用户要求检查的证书的序列号，以及请求者的IP地址。苹果当然有一个数据库，可以将序列号映射回实际的X.509证书，然后它很可能被用来识别这个证书被用来签名的应用程序。关于申请的元数据可能会被映射回你是谁(也许是通过AppleID的力量)，证书的属性可能与你的应用商店购买(或缺乏)绑定在一起。从理论上讲，这可以用来打击盗版、私人软件发行

但这里是我们必须考虑用户的地方。我日复一日地深陷系统安全问题的泥潭中。但是，我们与之互动的所有这些系统都变得更加复杂，我无法对正在发生的事情保持一个完整的心理图景。恶意软件隐藏在比我能想到的创造性脑细胞更多的地方，我运行的每个可执行程序包都让我想知道我可能会把王国的钥匙交给谁，特别是如果没有办法将这个包与构建它的原始开发者联系起来的话。在我看来，应用程序签名实际上是一件非常好的事情。如果说有什么不同的话，那就是它让我相信，在开发人员构建它的时候和我安装它的时候，这个包没有被篡改。

我一直反对像这样的选入安全特性，如果有选择退出会让用户不愉快。为什么？因为大多数用户无法评估选择退出安全流程的影响。一个全面的开关上写着禁用所有代码签名检查，这对许多用户来说是很难理解的含义。一旦设置了该开关，用户(很难记住密码)如何记住该设置已被更改？用户如何知道启用了控件的系统和没有启用控件的系统之间的区别？用户如何评估他们系统的这些状态之间的差异呢？

谷歌在Pixelbook的引导过程中采取了一种有趣的方式。当您启用从Google以外的来源引导签名图像时，引导时会弹出一个非常恼人的弹出窗口(如果内存正常的话，还带有声音效果)，它会提醒您正在引导不受信任的代码。这对开发人员来说很管用，但大多数用户会对这条消息的含义感到困惑，在网上搜索有关这条消息的答案大多会导致人们回答说，你应该完全忽略这条消息。不太好。

有人可能会说，苹果在这件事上迎合了最低公分母。这是有一定道理的--你不会想要对你的用户发动一场战争，然后认为他们是愚蠢的。但是，如果身为信息安全专业人士的人甚至不能告诉你各种控制措施的真正含义(鉴于这些系统的巨大复杂性)，普通用户怎么能做出这些决定呢？

最后，还有一个开放源码的论点--如果我有代码，构建代码，代码中就没有什么可以隐藏的。多亏了开源社区的有效营销，人们才相信了这一谬论。当今的软件系统是如此复杂，即使是最精心策划的代码库也潜伏着微妙的问题。你自己构建并运行的Chrome版本会不会比你从谷歌(Google)下载并由苹果(Apple)共同签名的Chrome版本在本质上更安全，或者更不可能受到攻击？当然不会(事实上，我会从另一个角度出发，但这与我们的谈话没有关系)，但如果包中嵌入了一些恶意软件，由苹果(Apple)联名签署的Chrome版本可能会被撤销(译者注：原文为“Chrome Build”，原文为“Chrome”，原文为“Chrome”，原文为“Chrome”)。这是一个有趣的控件，让用户受益匪浅。

隐私保护小组在这件事上动员起来--事实上，有一篇博文因为用狗哨来谴责这类系统而引起了很多关注！一些人关注了史诗巨人游戏的情况，堡垒之夜已经被从iOS(和安卓)上的App Store下架，作为这些系统可能导致的滥用的证据。老实说，他们的观点是有道理的--在狭隘的话语世界里。

归根结底，这是一个信任的争论--你相信苹果的行为符合你的最大利益，还是你认为他们是一个恶毒的实体？对个人来说，像苹果那样维护值得信赖或不值得信赖的人的名单是不可行的。大多数用户也不能运行监控恶意应用程序的安全程序。这是典型的防病毒情况--传统防病毒之所以有任何价值，唯一的原因是某个地方的某个人必须先体验到病毒，然后将其报告给防病毒供应商，然后由防病毒供应商提供签名。但仅靠你自己复制这一点是不可行的，你需要众包和广泛的网络来及早得到这些报告的回应。

或许更多的透明度将有助于缓解人们对滥用数据的担忧。让一个可审计的第三方运行OCSP响应器来进行应用程序证书检查，将缓解人们对苹果滥用这些数据的担忧。苹果可能会在不放松其提供的平台安全模型的情况下，做出一些微调来提高透明度。

在OCSP响应器中断，MacOS Big Sur发布后尘埃落定之后，有很多人合理地询问，他们是否可以相信苹果会参与决定哪些应用程序应该在Mac电脑上运行，哪些应用程序不应该在Mac电脑上运行。我的观点是--还有谁比苹果更好呢？

微软同上-Windows已经取得了惊人的进步，超越了其他操作系统提供的控制，为用户提供了极大的简单性，同时专注于验证谁编译了在用户PC上运行的代码。对这个过程的信任是至关重要的(这就是为什么Stuxnet驱动程序签署证书私钥被盗是一个巨大的打击)，最终是一个商业(个人)决定。

虽然我的话听起来像是苹果的辩护者，但我认为有关隐私的争论有些牵强。即使我们让他们得出极端的结论，苹果允许用户禁用他们提供的所有控制，我们也只会带来更多的伤害而不是好处。苹果当然有机会滥用他们获得的数据(哦，天哪，他们有很多关于用户的数据吗)，但我又一次想到了Reddit、Facebook、谷歌和PornHub等公司的平均用户数据，我问自己，谁最有权危及一个人的生活？

Reddit知道你在搜索什么，你访问了哪些子Reddit论坛，甚至在那个隐姓埋名的窗口中也是如此。我还确信，PornHub会按IP地址和日期对搜索中的每一个查询进行索引。如果你认为这很难追溯到某个特定的人身上，我有个坏消息要告诉你，来自长岛的史蒂夫。