如果攻击者对你执行中间人攻击（MITM），他们只要阻止吊销请求，让人觉得好像CA宕机。然后浏览器会对检查进行软失效处理，继续开心地使用已吊销的证书。每当你浏览并遇到该证书，又没有受到攻击，你都要承受这笔开销：执行吊销检查，查明证书没有被吊销。

谷歌的亚当·兰利（Adam Langley）对吊销性质作了最生动的描述：它好比是安全带，车辆碰撞后迅速发挥保护作用。他说的没错。你每天钻进汽车，系上安全带，让你觉得貌似很安全。后来有一天，出现了状况――你撞车了，从挡风玻璃钻了出来。就在你需要它的时候，它却让你失望。

解决问题

眼下，没有一种可靠的方法来解决这个问题。吊销机制是坏的。不过有几种机制值得一提，将来我们会有一种可靠的吊销检查机制。

专有机制

如果网站中招，攻击者拿到了私钥，他们会冒充该网站，大搞破坏。这可不妙，但结果可能更糟。如果CA中招，攻击者获取了中间证书的签名私钥，会怎样？这将是一场灾难，因为攻击者随后只要给自己的证书签名，就可以冒充他们想要冒充的任何网站。Chrome和Firefox都有各自的机制（其工作原理一样），而不是对中间证书的吊销执行在线检查。

CRLsets和OneCRL

Chrome将其机制称为CRLsets，Firefox将其机制称为OneCRL，它们通过合并可用的CRL，从中选择需要加入的证书来管理吊销证书列表。所以，我们包括了像中间证书这样的高价值证书。

OCSP Must-Staple

为了解释“OCSP Must-Staple”是什么，我们先需要大致介绍OCSP封套（OCSP stapling）的背景。我不会作太多的介绍，可以去我的博客了解OCST封套（https://scotthelme.co.uk/ocsp-stapling-speeding-up-ssl/），不过核心内容是：OCSP封套提供了OCSP响应以及证书，让浏览器没必要执行OCSP请求。它之所以被称为“OCSP封套”，是由于其想法是，服务器会“封套”OCSP对证书的响应，并将两者一并提供。

OCSP封套的实际运作

乍一看，这似乎有点奇怪，因为服务器几乎将其自己的证书“自我认证”为未吊销，但它都能检查出来。OCSP响应仅在短时间内有效，由CA签名，签名方式与签名证书的方式一样。因此，正如浏览器可以验证证书绝对来自CA，它也可以验证OCSP响应来自CA。这解决了OCSP重大的隐私问题，还消除了客户要执行这个外部请求的负担。完胜！

不好意思，但实际上并不那么好。OCSP封套是很好，我们在自己的网站上都应该支持它，但是坦率地说我们认为攻击者会启用OCSP封套吗？不，他们当然不会。我们需要一种方法迫使服务器进行OCSP封套，这就是OCSP Must-Staple的用途。我们向CA请求证书时，要求对方在证书中设置OCSP Must-Staple标志。这个标志告诉浏览器：证书在提供时必须附有OCSP封套，否则将被拒绝。设置标志很容易。

CSR中的OCSP must-staple

鉴于我们有了该标志已设置的证书，我们（主机）必须确保我们采用OCSP封套，否则浏览器不接受我们的证书。万一中招、攻击者获得我们的密钥，他们在使用我们的证书时还要提供OCSP封套。如果他们不附上OCSP封套，浏览器将拒绝证书。如果他们果真附有OCSP封套，那么OCSP响应会说证书已吊销，浏览器将拒绝。哇哦！

攻击者企图使用must-staple证书

OCSP Expect-Staple

虽然Must-Staple听起来是解决吊销问题的好办法，它其实还没有到位。我发现最大的问题之一是，作为网站运营者，我实际上不知道OCSP封套有多可靠、客户对封套的响应又是否满意。要是未启用OCSP Must-Staple，这其实不是个问题，但如果我们果真启用OCSP Must-Staple，然后又没有适当地或可靠地使用OCSP封套，我们的网站会开始出问题。