7. 安全考虑事项

7.1. 恶意头字段攻击

当 UA 支持 Expect-CT 头字段时, 它会成为针对站点所有者的恶意头字段攻击的潜在向量. 如果站点所有者使用的证书由既不嵌入 SCT, 也不通过 Online Certificate Status Protocol (OCSP) 或 TLS 扩展提供 SCT 的证书颁发机构签发, 则恶意服务器运营者或攻击者可以临时重新配置主机, 使其符合 UA 的 CT Policy, 并添加带有较长 max-age 的强制模式 Expect-CT 头字段. 实现该机制的用户代理会将其记录为 Expect-CT Host (见第 2.3.2.1 节). 完成之后, 配置可以再恢复为不符合 CT Policy, 从而触发失败. 注意, 这种场景要求攻击者对相关基础设施具有相当程度的控制权, 能够获取不同证书, 修改服务器软件, 或在连接中充当中间人.

站点运营者可以通过以下方式之一缓解这种情况: 重新配置其 Web 服务器, 使用 [RFC9162] 第 6.5 节定义的 TLS 扩展传输 SCT. 从另一个能够通过其他方法之一提供 SCT 的证书颁发机构获取证书. 或等待用户代理对该 Expect-CT Host 的持久记录达到其 max-age. 如第 4 节所述, 用户代理可以选择实现允许用户修复这种情况的机制.

7.2. 最大 max-age

这里存在安全权衡: 较低的最大值只能为不常访问 Known Expect-CT Host 的用户提供较窄的保护窗口, 而较高的最大值在发生恶意头字段攻击, 或者站点所有者单纯配置错误时, 可能导致对 UA 的拒绝服务.

max-age 指令可能不存在理想的最大值. 由于 Expect-CT 主要是一种策略扩展和调查技术, 而不是最终用户保护机制, 因此约 30 天 (2,592,000 秒) 的值可被视为在这些相互竞争的安全关切之间取得平衡.

7.3. 放大攻击

另一类恶意头字段攻击会在许多当前未公开 SCT 的主机上使用 report-uri 机制, 以此对接收报告的主机造成拒绝服务. 如果一些高流量网站发出带 report-uri 的非强制 Expect-CT 头字段, 实现该机制的 UA 所发送的报告可能淹没报告主机. 第 2.1.1 节指出 UA 应限制其发出报告的速率, 但攻击者可以修改 Expect-CT 头字段, 诱导 UA 向不同 URI 提交不同报告, 从而仍然造成相同效果.