跳到主要内容

7. 安全考虑 (Security Considerations)

本文整体都在讨论直接影响使用 TLS 协议的应用的安全实践.本节包含与 TLS 结合使用或由 TLS 使用的技术相关的更广泛安全考虑.更多上下文见 TLS 1.3 [RFC8446]、DTLS 1.3 [RFC9147]、TLS 1.2 [RFC5246] 和 DTLS 1.2 [RFC6347] 的安全考虑章节.

7.1. 主机名验证 (Host Name Validation)​

应用作者应注意, 某些 TLS 实现不会验证主机名.如果所使用的 TLS 实现不验证主机名, 作者可能需要自行编写验证代码, 或考虑使用其他 TLS 实现.

主机名验证的要求, 以及一般而言 TLS 层与其上运行协议之间绑定的要求, 会因协议而异.对于 HTTPS, 这些要求由 [RFC9110] 第 4.3.3、4.3.4 和 4.3.5 节定义.

主机名验证对所有常见 TLS 用例都至关重要.没有它, TLS 只能确保证书有效并保证对端拥有私钥, 但不能确保连接终止于期望端点.TLS 上下文中通用主机名验证的更多细节见 [RFC6125].此外, 该 RFC 包含大量应用协议, 其中一些协议采用与 HTTPS 非常不同的策略.

如果主机名是通过间接且不安全的方式发现的, 例如通过明文 DNS 查询 SRV 或 Mail Exchange (MX) 记录, 即使它与呈现证书匹配, 也不应把它用作参考标识符 [RFC6125].如果主机名是安全发现的, 则不适用该限制.进一步讨论见 [RFC7673] 和 [RFC7672].

主机名验证通常只适用于叶子 "终端实体" 证书.当然, 为在 PKI 上下文中确保正确认证, 应用客户端需要按照 [RFC5280] 验证完整认证路径.

7.2. AES-GCM​

第 4.2 节建议使用 AES-GCM 认证加密算法.AES-GCM 与 TLS 一起使用时专门适用的安全考虑见 [RFC5288] 第 6 节.

7.2.1. TLS 1.2 中的 nonce 复用 (Nonce Reuse in TLS 1.2)​

[Boeck2016] 记录了已部署 TLS 栈错误复用 AES-GCM nonce 的情况, 表明 AES-GCM 确实存在被不安全实现的风险, 从而使使用 AES-GCM 密码套件的 TLS 会话易受 [Joux2006] 等攻击影响.相关 [CVE] 记录包括 CVE-2016-0270、CVE-2016-10213、CVE-2016-10212 和 CVE-2017-5933.

TLS 1.3 已修复该问题, 它对所有 AEAD 密码套件, 包括 AES-GCM, 强制采用从记录序列号和共享秘密生成 nonce 的确定性方法.不过, TLS 1.2 实现仍可选择自己的 nonce 生成方法, 其中可能是不安全的.

因此, 推荐 TLS 1.2 实现使用 64 位序列号填充 GCM nonce 的 nonce_explicit 部分, 如 [RFC8446] 第 5.3 节前两段所述.该更强建议更新了 [RFC5288] 第 3 节, 后者规定使用 64 位序列号填充 nonce_explicit 字段是可选的.

撰写本文时, 尚未为 AES-GCM-SIV [RFC8452] 等抗 nonce 复用算法定义密码套件.

7.3. 前向保密 (Forward Secrecy)​

前向保密, 也称 "完美前向保密" 或 "PFS", 定义见 [RFC4949], 是对一种攻击者的防护: 攻击者记录加密会话, 而会话密钥只由通信双方的长期密钥加密.

如果攻击者后来能够获得这些长期密钥, 会话密钥以及整个会话内容都可能被解密.

在 TLS 和 DTLS 上下文中, 长期密钥被攻陷并非不可想象.可能原因包括:

  • 客户端或服务器受到其他攻击向量攻击, 私钥被取回.

  • 从出售或退役前未擦除的设备中取回长期密钥.

  • 设备使用长期密钥作为默认密钥 [Heninger2012].

  • 可信第三方, 例如 CA, 生成密钥后, 攻击者通过勒索或入侵从其处取回密钥 [Soghoian2011].

  • 密码学突破, 或使用长度不足的非对称密钥 [Kleinjung2010].

  • 针对系统管理员的社会工程攻击.

  • 从保护不足的备份中收集私钥.

在这些情况下, 前向保密确保即使攻击者在会话结束后一段时间取得长期密钥, 也不可行地确定会话密钥.它还可防护持有长期密钥但在会话期间保持被动的攻击者.

前向保密通常通过 Diffie-Hellman 方案派生会话密钥实现.Diffie-Hellman 方案要求双方保持私有秘密, 并在网络上发送特定循环群上的模幂参数.所谓离散对数问题 (DLP) 的性质允许双方派生会话密钥, 而窃听者无法做到.目前, 如果选择足够大的参数, 尚无已知攻击可破解 DLP.Diffie-Hellman 的一种变体使用椭圆曲线而非最初提出的模算术.以当前技术水平看, 椭圆曲线 Diffie-Hellman 更高效, 允许更短密钥长度, 且实现错误空间小于有限域 Diffie-Hellman.

遗憾的是, 许多 TLS/DTLS 密码套件不具备前向保密, 例如 TLS_RSA_WITH_AES_256_CBC_SHA256.因此, 本文主张严格使用仅支持前向保密的密码.

7.4. Diffie-Hellman 指数复用 (Diffie-Hellman Exponent Reuse)​

出于性能原因, TLS 实现复用 Diffie-Hellman 和椭圆曲线 Diffie-Hellman 指数跨多个连接并不少见.这种复用可能导致严重安全问题:

  • 如果指数复用时间过长, 某些情况下短至数小时, 攻击者一旦访问主机就可解密先前连接.换言之, 指数复用抵消前向保密的效果.

  • 复用指数的 TLS 实现应测试收到的 DH 公钥是否属于相应群, 以避免某些已知攻击.撰写本文时, TLS 中尚未标准化这些测试, 尽管 [NIST.SP.800-56A] 提供了该领域的一般指导, 且许多协议实现中已有相关测试.

  • 在某些条件下, 使用静态有限域 DH 密钥, 或跨多个连接复用的临时有限域 DH 密钥, 可能导致针对 Diffie-Hellman 密钥交换中共享秘密的计时攻击, 例如 [RACCOON] 中描述的攻击.

  • 如果受害者不验证接收点位于正确曲线上, 椭圆曲线 DH 可能遭受 "无效曲线" 攻击.如果受害者复用 DH 秘密, 攻击者可通过改变点重复探测并恢复完整秘密, 见 [Antipa2003] 和 [Jager2015].

为处理这些问题:

  • TLS 实现不应使用静态有限域 DH 密钥, 且不应跨多个连接复用临时有限域 DH 密钥.

  • 希望复用椭圆曲线 DH 密钥的服务器实现, 应使用 "安全曲线 (safe curve)" [SAFECURVES], 例如 X25519, 或对接收点执行 [NIST.SP.800-56A] 中描述的检查.

7.5. 证书吊销 (Certificate Revocation)​

以下考虑和建议代表了证书吊销方面的当前技术水平, 尽管检查常见公钥证书 [RFC5280] 吊销状态的问题尚无完整且高效的解决方案:

  • 从 TLS 实现被攻击以及证书误签发中恢复时, 证书吊销是重要工具.TLS 实现必须实现不信任已吊销证书的策略.

  • 证书吊销列表 (CRL) 是分发吊销信息支持最广泛的机制, 但存在已知扩展性挑战, 限制了其实用性, 尽管存在分区 CRL 和增量 CRL 等变通方式.较新的 [CRLite] 以及后续 Let's Revoke [LetsRevoke] 基于 Certificate Transparency [RFC9162] 日志和激进压缩, 使 CRL 基础设施具备实际可用性, 但撰写本文时, 二者都未在客户端侧吊销处理上大规模部署.

  • 把吊销列表嵌入 Web 浏览器配置数据库的专有机制, 无法扩展到少数最常用 Web 服务器之外.

  • 基本形式的在线证书状态协议 (OCSP) [RFC6960] 同时存在扩展性和隐私问题.此外, 客户端通常 "软失败", 即如果 OCSP 服务器不响应, 不会中止 TLS 连接.不过, 如果 OCSP 响应器离线, 这可能是避免拒绝服务攻击的变通方式.Web PKI 中 OCSP 部署状态的近期调查见 [Chung18].

  • TLS Certificate Status Request 扩展 [RFC6066] 第 8 节, 通常称为 "OCSP stapling", 解决了 OCSP 的运营问题.不过, 在存在主动路径攻击者时它仍然无效, 因为攻击者可直接忽略客户端对 stapled OCSP 响应的请求.

  • [RFC7633] 定义了一个证书扩展, 表示客户端必须期待该证书有 stapled OCSP 响应, 且如果该响应不可用, 必须中止握手, 即 "硬失败".

  • TLS 1.2 中使用的 OCSP stapling 不扩展到证书链中的中间证书.Multiple Certificate Status 扩展 [RFC6961] 处理了该缺陷, 但部署很少, 且已被 [RFC8446] 弃用.因此, 虽然 [RFC7525] 曾为 TLS 1.2 推荐该扩展, 本文不再推荐.

  • TLS 1.3 [RFC8446] 第 4.4.2.1 节允许通过 CertificateEntry 结构的扩展把 OCSP 信息与中间证书关联.不过, 使用该功能仍不实际, 因为许多认证机构 (CA) 要么不为 CA 证书发布 OCSP, 要么发布有效期过长而无用的 OCSP 报告.

  • CRL 和 OCSP 都依赖相对可靠的 Internet 连接, 而某些节点可能没有这种连接.常见示例是新配置设备, 它们需要建立安全连接才能首次启动.

对于 TLS 中公钥证书的常见用例, 在当前技术水平下, 并作为可能未来解决方案的基础, 服务器应支持以下最佳实践: OCSP [RFC6960] 以及使用 [RFC6066] 中定义的 status_request 扩展进行 OCSP stapling.注意, 嵌入 status_request 扩展的具体机制在 TLS 1.2 和 1.3 中不同.作为本地策略, 服务器运营者可以请求 CA 为服务器和/或客户端认证签发 must-staple [RFC7633] 证书, 但建议在决定采用前审查运营条件.

如果使用 DNS-Based Authentication of Named Entities (DANE) TLSA 资源记录 [RFC6698] 向客户端指示服务器认为对 TLS 连接有效且适合使用的证书, 本节考虑不适用.

最后于 更新