RIVALSA网络日志

从 OCSP 到 OCSP must-staple

于2022-05-09发布

本文原本于2019年5月7日发布在 RIVALSA 知识分享板块中,由于 RIVALSA 知识分享板块已下线,于2022年5月9日将本文转移至 RIVALSA 网络日志中。

HTTPS 是通过在 HTTP 的基础上加入 SSL 层,利用数字证书来保证通信不被窃听和篡改。这种模式的安全性在于私钥的绝对隐藏,为了防止私钥泄漏带来的危害,数字证书颁发机构(CA)可以帮助用户吊销证书,证书被吊销后,就不会在被客户端信任了。众所周知,目前常用的证书吊销方式有证书吊销列表(Certificate Revocation List,CRL)和在线证书状态协议(Online Certificate Status Protocol,OCSP)。本文只对 OCSP 做简单分析。

OCSP 如何工作及其存在的问题

在 CA 颁发证书时,就会在证书中写明此证书 OCSP 的验证地址,由于整个证书中有 CA 的签名,所以这个信息并不会被篡改。客户端在收到证书后并验证签名后,可以向证书中列出的这个接口发出请求,根据 CA 的响应来判断此证书当前的吊销状态,从而根据此证书的吊销状态来决定是否信任此证书。

但在此过程中,存在两个问题:

一、客户端与目标服务器建立连接并得到目标服务器的证书后,还需要与 CA 服务器建立连接去验证证书状态,此过程会增加页面加载时间;

二、如果由于黑客攻击或网络故障等原因导致客户端无法与 CA 服务器建立连接,则无法获取证书吊销状态,只能按照浏览器预定规则,接收(可能存在风险)或拒绝(可能会误伤)这个证书。

OCSP Stapling 的作用

OCSP Stapling 是在客户端向目标服务器发起请求后,由目标服务器端向 CA 服务器获取证书的吊销状态并在目标服务器中缓存一段时间,此吊销状态具有CA服务器签名的,可以保证无法被篡改。在目标服务器向客户端发送证书的同时,也将这个已经获取的证书吊销状态发送给客户端。这样在客户端在验证签名后,可以直接使用目标服务器返回的这个吊销结果,就不必自行去 CA 服务器验证了。

这个过程看上去很完善,但 OCSP Stapling 是需要服务器端支持的,只要私钥的非法持有者不开启 OCSP Stapling 功能,被吊销的证书还是有可能被黑客利用。针对此原因,就提出了证书的另一个扩展 OCSP must-staple。

OCSP must-staple 及其配置

OSCP must-staple 是证书上的一个标记,客户端收到具有此标记的证书,但却没有收到 OCSP Stapling 则会拒绝此证书,这样就保证了被吊销的证书不会被非法利用,那么如何生成带有此扩展的证书呢?首先目前并不是所有的 CA 都支持签发具有次标记的证书,据本站所知,目前只有 Let's encrypt 可以签发带有此扩展的证书。其次,在生成证书 CSR 前,需要进行如下配置(下例是利用 OpenSSL 生成 CSR 的配置):

修改openssl.cnf中的内容,在[v3_req]中添加1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
1.3.4.1.5.5.7.1.24 = DER:30:03:02:01:05

如果是使用 openssl 1.1.0 或更高的版本,可以这样设置:添加 tlsfeature=status_request 即可。

[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
tlsfeature = status_request

使用以上配置生成的 CSR,提交给支持 OCSP must-staple 的 CA 签发出的证书就带有 OCSP must-staple 扩展了。

(正文完)

版权信息

本作品著作权归属 Rivalsa 所有,除非 Rivalsa 明确许可您使用,否则任何个人或组织不得以任何方式直接或间接的复制、伪造、转载、摘编、翻印、改编、演出或以其他方式使用本作品。

已获得0个赞0个差评

0条评论

发表评论(取消回复)

通知选项

确定

是否 AT 其他评论者

不 AT 任何人