CRL其实是个很简单的概念，它就是一份列表，列出了CA标记为已吊销的所有证书。客户可以联系CRL服务器，下载一份列表。有了这份列表，浏览器可以检查：向它出示的证书是否在该列表中。如果证书在列表中，浏览器现在知道证书是坏的，不该信任它。浏览器应该会弹出错误信息，放弃连接。如果证书不在列表中，那么一切都很好，浏览器可以继续连接。

下载CRL

CRL的问题在于，它们含有来自负责维护的某个CA的许多吊销证书。因不了解太多细节，它们被CA拥有的每个中间证书搞坏，CA可能将列表分解更小的块。不管列表如何分解，我想要表明的意思仍然一样：CRL通常很庞大。另一个问题是，如果客户没有一份新的CRL，必须在最初连接到你网站时获取一份，这可能会让你网站加载看起来比实际上慢得多。

这听起来不是特别好，那我们不妨来看看OCSP如何？

在线证书状态协议

OCSP提供了一种好得多的办法来解决该问题，与CRL方法相比具有显著优势。使用OCSP，我们向CA询问某一个证书的状态。这意味着CA要做的就是回应证书是好的/已吊销的答案，这比CRL小得多。不赖！

获取OCSP响应

没错，OCSP在性能方面比获取CRL具有显著优势，但是这个性能优势有其代价。这也是相当大的代价：你的隐私。

如果我们考虑一下OCSP请求的是什么（请求一个非常特殊的证书的状态），开奖，你可能会开始意识到泄漏了一些信息。如果你发送OCSP请求，基本上是向CA问这个：

“pornhub.com的证书是否有效？”

所以，这根本不是一种理想的场景。现在你将自己的浏览记录内容通告给了你甚至一无所知的某个第三方，这完全以HTTPS的名义――而HTTPS原本旨在为我们加强安全和隐私。这是不是颇具讽刺意味？

硬失效

不过等等：还有别的方面。我在上面谈论了CRL和OCSP响应，这是浏览器可以用来检查证书是否被吊销的两种机制。它们看起来就像这样。

CRL和OCSP检查

浏览器一收到证书，就会联系这其中一个服务，并执行必要的查询，最终确定证书的状态。但是如果你的CA遭遇不幸、基础设施宕机，将会怎样？如果看起来像下面这种情况，将会怎样？

CRL和OCSP服务器宕机

这时候，浏览器只有两个选择。它可以拒绝接受证书，因为它无法检查吊销状态，或者在不知道吊销状态的情况下冒险接受证书。这两个选择各有优缺点。如果浏览器拒绝接受证书，那么每当你的CA遭遇不幸、基础设施又宕机，你的网站也会跟着宕机。如果浏览器继续接受证书，那么它就面临使用可能被盗的证书这个风险，因而将用户暴露于相关风险。

这是个艰难的选择――不过现在，这任何一种情况没有实际发生。

软失效

如今实际发生的是，浏览器会做我们所说的“软失效吊销检查”（soft fail revocation check）。也就是说，浏览器会试着检查证书吊销，但是如果响应没有返回，或者没有在短时间内返回，浏览器会完全不理。更糟糕的是，Chrome甚至根本不执行吊销检查。

是的，你没有看错，Chrome甚至不试着检查它遇到的证书的吊销状态。你可能觉得更奇怪的是，开奖，我完全认同Chrome的做法；我很高兴地说，Firefox看起来很快也会加入这个行列。

不妨听我细细道来。我们在硬失效方面遇到的问题很明显：如果CA遭殃，我们也跟着遭殃。这就是为何我们提到了软失效。浏览器现在试着执行吊销检查，但如果花太长时间，或者CA似乎宕机，它最终会放弃检查。

等等，如果“CA似乎宕机？”，就会放弃吊销检查。我在想攻击者会不会模仿这个？

攻击者阻止吊销检查