跳到主要内容

7. Security Considerations (安全考量)

7. Security Considerations (安全考量)​

在 CA, 日志与服务器执行本文所述行为的前提下, TLS 客户端可以利用日志与签名时间戳降低接受错误签发证书的可能性. 若服务器为某证书呈现有效签名时间戳, 则客户端知道该证书已在日志中公布. 由此, 客户端知道证书主体已有一段时间发现错误签发并采取某些行动, 例如要求 CA 撤销错误签发的证书. 签名时间戳并不保证证书未被错误签发, 因为证书主体可能未检查日志, 或 CA 可能拒绝撤销证书.

此外, 若 TLS 客户端不接受未记录的证书, 则站点所有者将有更强动机将证书提交给日志, 可能在其 CA 协助下, 从而提高整个系统的透明度.

7.1. Misissued Certificates (错误签发的证书)​

未公开记录因而没有有效 SCT 的错误签发证书将被 TLS 客户端拒绝. 拥有来自某日志的 SCT 的错误签发证书, 在日志正常运行前提下, 将在最大合并延迟内出现在该公开日志中. 因此, 错误签发证书可在不被审计的情况下使用的最长时间为 MMD.

7.2. Detection of Misissue (错误签发的检测)​

日志本身不检测错误签发的证书; 它们依赖感兴趣方 (例如域名所有者) 监视日志并在检测到错误签发时采取纠正措施.

7.3. Misbehaving Logs (行为不当的日志)​

日志可能以两种方式不当运行: (1) 未在 MMD 内将带有 SCT 的证书纳入 Merkle 树; (2) 违反仅追加属性, 在不同时间和/或向不同方呈现两种不同, 冲突的 Merkle 树视图. 两种违规形式都将被迅速且公开地检测到.

违反 MMD 合约可通过日志客户端对每个观测到的 SCT 请求 Merkle 审计证明来检测. 这些检查可以异步进行, 且每个证书只需执行一次. 为保护客户端隐私, 这些检查不必向日志暴露确切证书. 客户端可以改为从可信审计者请求证明 (因为任何人都可以从日志计算审计证明), 或请求围绕 SCT 时间戳的一批证书的 Merkle 证明.

违反仅追加属性可通过全局八卦检测, 即审计日志的各方比较其最新签名树头版本. 一旦检测到同一日志的两个冲突签名树头, 即构成该日志不当行为的密码学证明.

最后于 更新