5. 安全考虑

5. 安全考虑

为使该服务有效, 使用证书的系统必须连接到证书状态服务提供方.如果无法建立此类连接, 使用证书的系统可以实现 CRL 处理逻辑作为回退方案.

面对查询洪泛时, 拒绝服务漏洞十分明显.生成加密签名会显著影响响应生成周期, 从而加剧这一情况.未签名的错误响应会使协议暴露于另一类拒绝服务攻击, 即攻击者发送虚假的错误响应.

使用预计算响应会允许重放攻击: 旧的 (良好) 响应在其过期日期之前,但在证书已被撤销之后被重放.OCSP 部署应仔细权衡预计算响应的收益, 以及重放攻击发生的概率和攻击成功后产生的成本.

请求不包含其目标响应方.这使攻击者能够将请求重放给任意数量的 OCSP 响应方.

在某些部署场景中依赖 HTTP 缓存时, 如果中间服务器配置错误或已知存在缓存管理缺陷, 可能产生意外结果.建议实现者在部署基于 HTTP 的 OCSP 时考虑 HTTP 缓存机制的可靠性.

如果请求者能够预测或猜测即将签发证书的证书序列号, 那么对从未签发过的证书返回 "revoked" 状态, 可能使某人能够为尚未签发但很快会签发的证书取得撤销响应.对于使用顺序证书序列号分配方式签发证书的 CA, 这种预测很容易.本规范通过要求符合要求的实现使用 certificateHold 原因码来处理这一风险, 从而避免永久撤销该序列号.对于支持针对未签发证书的状态请求返回 "revoked" 响应的 CA, 完全避免此问题的一种方式是分配具有高熵的随机证书序列号值.

5.1. 首选签名算法

用于选择响应签名算法的机制 MUST 被认为对于目标应用而言足以抵抗密码分析攻击.

在大多数应用中, 签名算法至少与用于签署被查询状态的原始证书的签名算法同样安全即可.但是, 在长期归档应用中, 这一准则可能不成立; 此类应用会查询遥远过去某个日期的证书状态, 而此时该签名算法早已不再被视为可信.

5.1.1. 不安全算法的使用

响应方并不总是能够生成客户端预期可理解且符合当前密码安全标准的响应.在这种情况下, OCSP 响应方运营者 MUST 权衡采用已受损安全方案的风险与强制升级的成本, 其中也包括终端用户所选择替代方案可能提供更低安全性甚至没有安全性的风险.

在归档应用中, OCSP 响应方很可能被要求报告证书在遥远过去某个日期的有效性.此类证书可能采用已不再被认为具有可接受安全性的签名方法.在这种情况下, 响应方 MUST NOT 使用不再被认为具有可接受安全性的签名机制生成签名.

客户端 MUST 接受响应中使用的,且由其在请求中指定为首选签名算法的任何签名算法.因此, 客户端 MUST NOT 将任何不支持或不被认为具有可接受安全性的算法指定为首选签名算法.

5.1.2. 中间人降级攻击

支持客户端指示首选签名算法的机制未受到针对中间人降级攻击的保护.此限制不被视为重大的安全问题, 因为即使客户端提出请求, OCSP 响应方也 MUST NOT 使用弱算法签署 OCSP 响应.此外, 无论使用何种机制确定响应的签名算法, 客户端都可以拒绝不满足其自身可接受密码安全标准的 OCSP 响应.

5.1.3. 拒绝服务攻击

本文档定义的算法敏捷性机制略微增加了拒绝服务攻击面, 因为客户端请求可能被篡改为要求服务器不支持的算法.RFC 4732 [RFC4732] 中讨论的拒绝服务考虑事项适用于本文档.