问普通OCSP和OCSP装订的确切区别是什么？

EN

OCSP装订比普通OCSP更有效，并且提供了更好的隐私。

OCSP协议用于确定证书是否仍然有效或是否已被撤销。例如，您希望通过TLS安全地连接到网站。为了确保证书没有被撤销或过期，浏览器可以向相应的证书颁发机构发出OCSP请求。在收到证书有效性的签名确认后，然后继续进行TLS握手。

这个过程有一些缺点:联系CA会花费时间，并且会减慢您的浏览体验。它还可能为CA创建高流量，向CA公开您正在访问的网站，并且您必须始终依赖OCSP响应程序的可用性，因为否则无法确认--尽管没有确认，您必须在接受证书还是中止连接之间作出决定。出于这些原因，谷歌Chrome 放弃了支持的普通OCSP。

OCSP装订通过让服务器周期性地发出OCSP查询来避免这些问题。web服务器将在TLS握手期间向您显示OCSP响应，而不是让用户执行有效性检查。服务器执行OCSP查询本身并不是安全问题，因为响应已经由CA签名并包含时间戳，从而防止了篡改。由于服务器缓存响应，CA不再被OCSP请求淹没，并且作为用户，您不需要与第三方联系来验证有利于您隐私的证书。

在@Arminius的回答中添加一些内容：

• 客户端发起的OCSP请求和OCSP装订仍然有一个问题--没有响应的OCSP应答者。无论是客户端，还是正在认证的服务器，得到OCSP响应的是响应者都是相同的。如果响应者倒下了，整个安全保障就会崩溃。

没有有效的OCSP答复的处理方式有两种：

1. “硬失败”--浏览器可以在页面上显示警告，说明连接可能受到破坏，并要求用户单击警告才能浏览所述服务器。
2. 软故障浏览器尝试获取有效的OCSP响应(从响应方或服务器发送的证书获得OCSP主板)，但在失败的情况下继续连接，并忽略没有有效的OCSP响应。

为了保持可用性，浏览器通常更喜欢第二种方法。

很难说一条路比另一条更安全。OCSP的主食确实减少了响应程序的负载，减少了它被真正的请求变成DOS-d的机会。服务器端缓存的响应大大加快了速度，并减少了浏览器上的负载，以完成OCSP的繁重工作。也就是说，攻击者可能仍然可以使用DDOS作为OCSP响应程序，甚至阻止真正的服务器获得有效的OCSP主板。

然而，OCSP的装订已经导致了很多性能的提高，正如来自Cloudflare的尼克·沙利文在他的博客中发表的这简短但精彩的文章所解释的那样。如果我们能够解决没有响应的OCSP问题，并且能够找到一种方法确保始终会出现一个ocsp响应，那么就可以使用ocsp-必备品扩展来生成证书。如果这一措施到位，将意味着比没有ocsp主食更有力的安全保障。