最后，杰夫·约翰逊（Jeff Johnson）的推文清楚地表明了根本原因。事实证明，Apple的OCSP Responder服务太重了，因此macOS无法验证应用程序开发人员的加密证书。
但是，为什么OCSP Responder处于启动应用程序的关键路径上？在本文中，我们将简要讨论代码签名，联机证书状态协议（OCSP）的工作原理，为什么完全错误以及某些最佳选择。与此事件的其他帖子不同，我想（从高层次）讨论实际的加密方面，并提供一个平衡的观点。
代码签名
在开发人员门户上，Apple解释了代码签名的目的：
对应用程序的代码进行签名可确保用户来自已知来源，并且自上次签名以来未对其进行过修改。必须先使用Apple发行的证书对应用程序进行签名，然后才能将其集成，安装在设备上或输入应用程序目录。
换句话说，要使应用程序在macOS上受信任，需要使用自己的基于密钥对的证书对其进行签名。钥匙串用于创建唯一的“开发人员ID”证书，其中包括供开发人员使用的私钥和用于分发的公钥。苹果签署了开发人员ID证书后，开发人员可以使用私钥在每个发行版的应用程序上创建加密签名。
启动应用程序时，将根据开发人员证书的公钥验证其签名。然后，对证书本身进行验证，以确保证书尚未过期（证书通常有效期为一年），并最终由Apple根证书签名。在根证书之前，中间证书也可以作为链的一部分。这是“信任链”，因为开发人员ID证书是由应用程序签名的，中间证书是由开发人员ID证书签名的，而Apple根证书是由中间证书签名的。任何Apple设备都可以检查此信任链，因此可以批准启动该应用程序。
这类似于Internet的TLS公钥基础结构。但从根本上说，苹果也完全控制了自己的信任链。不允许其他CA颁发有效的代码签名证书，因为所有证书都必须绑定到Apple。
如果验证失败，则用户将看到一个可怕的窗口：
反馈
如果开发人员违反Apple政策或丢失其私钥会怎样？证书颁发机构必须立即吊销已颁发的证书。如果证书被恶意使用，则等待数天或数月才能自然过期是不可接受的，否则私钥的泄漏将使整个系统变得无用。
在这种情况下，证书被吊销。这是签名验证过程中的另一个步骤，该步骤涉及向证书颁发机构询问证书仍然有效。
在Internet上，这是以最简单的方式完成的。 CA向您提供了一个证书吊销列表（CRL），其中包含所有吊销的证书的序列号，并且您验证该证书不在列表中。但是，随着列表越来越长，浏览器停止使用此方法。尤其是在像Heartbleed这样的骇人听闻的漏洞利用之后，要求进行大量证书撤销。
联机证书状态协议（OCSP）是一种替代方法，使您可以实时验证证书。每个证书都包含一个内置的OCSP响应程序，它是您请求的URL，它告诉您证书是否已被吊销。就苹果而言，这是
ocsp.apple.com... 因此，现在，除了检查签名的加密有效性之外，每次启动该应用程序时，您都要在Apple网站上进行实时检查（带有一些缓存），以使他们仍然认为开发人员的证书是合法的。
OCSP可用性问题
OCSP的最大问题是外部服务成为单点故障。如果OCSP响应器关闭或不可用，会发生什么？我们只是拒绝验证证书（硬失败）吗？还是我们假装检查成功（软失败）？
苹果被迫使用软故障行为，否则应用程序将无法离线工作。由于OCSP响应程序传统上不可靠，并且即使CA响应程序暂时关闭，浏览器也希望加载站点，因此所有主要的浏览器也都实现了软故障行为。
但是软失败不是一个好的选择，因为通过对网络的控制，攻击者可以阻止对响应者的请求，并且将跳过检查。实际上，在此事件期间，这种错误的“修复”已在Twitter上广泛传播：流量被
ocsp.apple.com/ etc / hosts文件中的一行阻止。由于禁用OCSP不会引起任何明显的问题，因此许多人会暂时离开这一行。
事件
如果Apple的OCSP验证基于软故障，为什么在禁用OCSP响应器时应用程序会挂起？可能是因为这实际上是一个不同的故障：OCSP响应程序实际上并未完全禁用。只是效果不好。
由于来自全球数百万要更新到macOS Big Sur的用户的负担，Apple的服务器速度变慢，无法正确响应OCSP请求。但是，与此同时，它们运行良好，以至于软失败不起作用。
OCSP隐私问题
除了OCSP可用性问题之外，该协议最初并不是为了保护隐私而设计的。基本OCSP请求包括带有证书序列号的未加密的HTTP请求，该请求是向OCSP响应者发送的。这样，响应者不仅可以确定您感兴趣的证书，而且还可以确定您的ISP和其他任何人拦截数据包。Apple可以按顺序列出您打开的开发人员应用程序，而外部人员也可以这样做。
可以添加加密，并且有一个更好的，更私有的版本，称为OCSP装订，但Apple也没有这样做。在这种情况下，OCSP装订实际上没有任何意义，但是该技术说明OCSP默认情况下不应泄漏数据。
美好的未来
该事件在社区引起了热烈的讨论，一方指出“您的计算机不是您真正的计算机”，另一方则说“建立对应用程序的信任很困难，但苹果做得很好。”我试图证明OCSP无论如何都是管理证书吊销的一种糟糕方法，并且将来它将导致更多与响应者可用性和隐私有关的事件。我认为这是一个错误的工程决策-设置应用程序启动器对OCSP的依赖关系。至少在短期内，他们通过增加响应缓存时间来减轻损害。
幸运的是，撤销证书的最佳方法CRLite几乎已经成熟。它允许您将所有证书吊销列表缩短到合理的大小。在Scott Helme的博客中，很好地总结了CRLite如何使用Bloom过滤器返回旧方法以及一系列已吊销的证书，这些证书一直运行到OCSP。
MacOS设备可能会定期接收对此CRL的更新，并在设备上本地执行检查，以解决OCSP可用性和隐私问题。另一方面，由于开发人员ID吊销列表比所有PKI吊销证书的列表小得多，因此值得一提的是，为什么Apple不使用CRL。他们可能不想透露哪些证书已被吊销。
结论
总体而言，此事件是反思苹果和微软等组织促进的信任模型的一个很好的理由。恶意软件已经变得更加复杂，大多数人无法确定运行某些二进制文件是否安全。代码签名似乎是一种建立对应用程序的信任并至少将应用程序与知名开发人员链接的绝佳加密方法。吊销证书是这种信任的必要部分。
但是OCSP验证过程中的一些小故障破坏了代码签名和验证过程的加密优雅性。 OCSP还被广泛用于Internet上的TLS证书，但是由于CA数量众多以及浏览器对故障的普遍无知，因此故障的灾难性较小。而且，人们习惯于不时看到不可用的网站，但是他们并不希望自己计算机上的应用程序会出现同样的情况。 MacOS用户担心自己的应用程序会受到Apple基础设施问题的影响。但是，这是不可避免的结果，这是由于证书验证取决于外部基础结构，并且没有任何基础结构是100％可靠的。
斯科特·赫尔姆（Scott Helme）还对吊销证书真正有效的证书颁发机构的权力表示担忧。即使您不担心审查的可能性，有时也会发生错误，并应权衡安全性。正如一名开发人员在Apple错误地吊销其证书时发现的那样，在孤立的平台上运行的风险是您可以与之隔离。