OCSP stapling

当访问HTTPS的网站，网站会给浏览器返回证书，证书中包含了公钥、证书过期时间等信息，这些信息被证书的签发者（即CA）使用自身私钥签名，浏览器有这些CA的根证书且相信这些CA，经过CA签名过的网站证书，浏览器是相信的。当浏览器收到网站返回的证书后，查看证书的过期时间，如果证书已过期，浏览器直接拒绝。
一切看起来都很美好，但有一些特殊情况存在，比如网站私钥泄露，此时必须有一种方法，能够人为标记证书无效，即使证书在有效期内。早期，CA通过CRL（certificate revocation lists）来完成这项工作。CRL就像一个公告牌，问题证书会被更新在上面。浏览器在HTTPS连接建立前需要查询证书签发CA的CRL，以保证服务器返回的证书是真实有效的，很明显这是件低效的工作，特别当CRL变得很长时，查询耗时会非常长。
为了解决上面的问题，OCSP（Online Certificate Status Protocol）出现了，CA不再需要维护CRL这种冗长的列表，它仅需要维护一个简单的HTTP服务器---OCSP Responders。浏览器在得到网站的证书后，通过证书中提供的信息（如下图），请求OCSP Responder就可以得到证书的状态信息，时间复杂度从原先的O(n)变成了O(1)。

ocsp URL

OCSP相对于CRL确实效率提高不少，但引入了下面问题：

• 浏览器收到一个新的证书就需要联系Responder来确认证书的状态，增加了HTTP的连接数，特别当站点通过CDN节点加速时，CDN的域名有非常多个，验证证书的负担会加重

• Responder的稳定性并不是100%的，即使服务器可以非常稳定的运行，线路延迟（Responder据小编所知都是国外的）等因素也会直接导致证书验证的失败，如下图浏览器与Responder间的通信耗费了4s多：

  
  ocsp timeout

• 因为Responder的低可靠性，现在的浏览器和web客户端对于OCSP检测，工作在soft-fail模式。它们容忍检测失败，在失败的情况下客户端认为证书有效，这就引入了安全问题，攻击者可以阻止浏览器对Responder的web访问，这样即使证书已经被吊销，浏览器还是会认为证书有效

• 此外，还有隐私性的问题，浏览器会将使用者的浏览记录泄露给Responder，我们只能祈求Responder都是有良知的
  为了解决上述问题，OCSP stapling出现了，它将验证证书有效性的工作由原来的浏览器等Web客户端转移到了Web服务器，而且验证信息可以缓存，这就极大的减少了HTTP的延时（浏览器到Web服务器之间的网络大都是好于浏览器到Responder的网络）。Web服务器返回给浏览器的证书状态信息因为有CA的签名，所以安全性是有保证的，中间人不太可能伪造。
  Apache配置OCSP stapling：

SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
<VirtualHost *:443>
SSLEngine on
SSLProtocol all -SSLv3 -SSLv2
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/CA.crt
SSLUseStapling on
</VirtualHost>

（Apache web服务器有个问题，当与CA Responder沟通出现超时等网络问题时，浏览器会删掉已经缓存的stapling信息，直接返回空的stapling信息或者错误的stapling信息）
OCSP stapling也不是完美的，它没有解决soft-fail，Stapling在服务器端实现，客户端不知道服务器是否支持stapling。如果攻击者提供了一个伪造的证书但没有OCSP stapling信息，客户端不清楚服务器是否支持stapling，所以它会像原来一样去Responder那里查询信息，此时攻击者可以阻塞浏览器到Responder之间的连接，那么浏览器就会信任攻击者的证书。OCSP Must-Staple可以解决这个问题，使用该技术需要重新配置网站证书。它通过证书的一个扩展字段实现，当浏览器收到有该扩展字段的证书，但是网站却没有返回stapling信息，浏览器会直接拒绝该证书。
参考文档：
https://www.digicert.com/kb/ssl-support/apache-enable-ocsp-stapling-on-server.htm
https://www.ssl.com/article/page-load-optimization-ocsp-stapling/
https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/