跳到主要内容

4. 建议: 密码套件 (Cipher Suites)

TLS 1.2 在密码套件选择上提供了相当大的灵活性.不幸的是, 其中一些密码套件的安全性随时间下降, 已知有些已经不安全, 这也是 TLS 1.3 限制这种灵活性的原因之一.服务器配置错误会导致没有安全性或安全性降低.本节给出关于密码套件选择和协商的建议.

4.1. 通用指南 (General Guidelines)​

随着密码分析进展, 加密算法会逐渐削弱: 曾被认为强的算法会变弱.因此, 使用弱算法的密码套件需要逐步淘汰, 并替换为更安全的密码套件.这有助于确保期望的安全属性仍然成立.SSL/TLS 已存在二十多年, 各版本中曾推荐的许多密码套件如今已被认为较弱, 或至少不再达到期望强度.因此, 本节更新关于密码套件选择的建议.

  • 实现禁止协商使用 NULL 加密的密码套件.

    理由: NULL 密码套件不加密流量, 因而不提供机密性服务.网络中任何可访问该连接的实体都能查看客户端和服务器交换内容的明文.不过, 本文并不反对软件实现 NULL 密码套件, 因为它们可用于测试和调试.

  • 实现禁止协商 RC4 密码套件.

    理由: [RFC7465] 记录了 RC4 流密码的多种密码学弱点.注意, DTLS 已明确禁止使用 RC4.

  • 实现禁止协商提供少于 112 位安全性的密码套件, 包括所谓 "export-level" 加密, 即提供 40 位或 56 位安全性.

    理由: 根据 [RFC3766], 至少需要 112 位安全性.所谓 "export ciphers" 中的 40 位和 56 位安全性如今被认为不安全.

  • 实现不应协商使用低于 128 位安全性算法的密码套件.

    理由: 提供不少于 112 位但低于 128 位安全性的密码套件当前不被视为弱套件, 但预计其可用寿命足够短, 因而现在支持更强密码套件是合理的.128 位密码预计在未来数年内保持安全, 256 位密码预计可持续到下一次基础技术突破.注意, 由于所谓 "中间相遇 (meet-in-the-middle)" 攻击 [Multiple-Encryption], 一些旧密码套件, 例如 168 位 Triple DES (3DES), 的有效密钥长度小于其名义密钥长度, 3DES 情况下为 112 位.此类套件应按有效密钥长度评估.

  • 实现不应协商基于 RSA 密钥传输的密码套件, 即 "static RSA".

    理由: 这些套件的分配值以 "TLS_RSA_WITH_*" 开头, 存在多个缺点, 尤其是不支持前向保密.

  • 实现不应协商基于非临时 (静态) 有限域 Diffie-Hellman (DH) 密钥协商的密码套件.同样, 实现不应协商非临时椭圆曲线 DH 密钥协商.

    理由: 前者的分配值以 "TLS_DH_" 为前缀, 存在多个缺点, 尤其是不支持前向保密.后者 "TLS_ECDH_" 同样缺少前向保密, 且易受无效曲线攻击 [Jager2015].

  • 实现必须支持并优先协商提供前向保密的密码套件.不过, TLS 1.2 实现不应协商基于临时有限域 Diffie-Hellman 密钥协商的密码套件, 即 "TLS_DHE_*" 套件.这样做的理由是该构造已知脆弱, 见 [RACCOON], 且协商能力受限, 包括 [RFC7919] 的采用也非常有限.

    理由: 前向保密, 有时称为 "完美前向保密", 可防止恢复使用旧会话密钥加密的信息, 从而限制攻击成功后可解密数据的时间范围.详见第 7.3 节和第 7.4 节.

4.2. TLS 1.2 的密码套件 (Cipher Suites for TLS 1.2)​

基于上述考虑, 推荐实现和部署以下密码套件:

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

由于这些是带关联数据的认证加密 (Authenticated Encryption with Associated Data, AEAD) 算法 [RFC5116], 这些密码套件只在 TLS 1.2 中受支持, 不适用于更早协议版本.

通常, 要优先使用这些套件, 需要在服务器软件中显式配置套件顺序.服务器软件实现若默认优先使用这些套件会更理想.

某些设备支持 AES Counter Mode with CBC-MAC (AES-CCM) 硬件, 但不支持 AES Galois/Counter Mode (AES-GCM), 因而无法遵循上述密码套件建议.也存在完全不支持公钥密码的设备, 但这些设备完全不在本文范围内.

除非同时成功协商 encrypt_then_mac 扩展 [RFC7366], 否则不应使用以 CBC 模式运行的密码套件, 例如 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.该要求同时适用于客户端和服务器实现.

使用 ECDSA 签名认证 TLS 对端时, 推荐实现使用 NIST 曲线 P-256.此外, 为避免可预测或重复 nonce 泄露长期签名密钥, 推荐实现 [RFC6979] 中规定且符合 [RFC8446] 建议的 "确定性 ECDSA (deterministic ECDSA)".

注意, "确定性 ECDSA" 实现可能因为其确定性而容易受到某些侧信道和故障注入攻击.文献中的多数故障注入攻击假定攻击者可物理接触设备, 因而更适用于物理安全较差或不存在的物联网 (IoT) 部署, 但也有一些攻击可远程执行 [Poddebniak2017], 例如 Rowhammer [Kim2014] 变体.在关注侧信道和故障注入攻击的部署中, 可使用同时结合随机性和确定性的实现策略, 例如 [CFRG-DET-SIGS] 中描述的方法, 以避免成功提取签名密钥的风险.

4.2.1. 实现细节 (Implementation Details)​

客户端应把 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 作为向任何服务器提出的第一个提案.只要客户端提出该密码套件, 服务器就必须优先于较弱密码套件选择它, 即使它不是第一个提案.客户端当然可以提供更强密码套件, 例如使用 AES-256; 如果客户端这样做, 除非有充分理由, 例如性能严重下降, 否则服务器应优先选择更强密码套件.

上一版 TLS 建议 [RFC7525] 隐式允许旧 RFC 5246 中必须实现的密码套件 TLS_RSA_WITH_AES_128_CBC_SHA.撰写本文时, 除了非常旧的客户端, 该套件已不再提供额外互操作性.与其他不提供前向保密的密码套件一样, 实现不应支持该套件.其他应用协议可能规定其他必须实现 (MTI) 的密码套件.

[RFC8422] 允许客户端和服务器协商 ECDH 参数, 即曲线.客户端和服务器都应包含 "Supported Elliptic Curves Extension" [RFC8422].客户端和服务器应支持 NIST P-256 (secp256r1) [RFC8422] 和 X25519 (x25519) [RFC7748] 曲线.注意, [RFC8422] 已弃用除未压缩点格式以外的所有点格式.因此, 如果客户端发送 ec_point_formats 扩展, ECPointFormatList 必须只包含一个元素: "uncompressed".

4.3. TLS 1.3 的密码套件 (Cipher Suites for TLS 1.3)​

本文不为 TLS 1.3 指定任何密码套件.密码套件建议见 [RFC8446] 第 9.1 节.

4.4. 密钥使用限制 (Limits on Key Usage)​

所有密码都有一个上限, 即任意给定密钥能够安全保护的流量数量.对于 AEAD 密码套件, 每个密钥维护两个单独限制:

  1. 机密性限制 (CL), 即可加密记录数量.

  2. 完整性限制 (IL), 即允许认证失败的记录数量.

后者适用于 DTLS, 也适用于 QUIC, 但不适用于 TLS 本身, 因为 TLS 连接会在第一次解密失败时被拆除.

当发送方接近 CL 时, 实现应发起新握手, 在 TLS 1.3 中可通过在已建立会话上发送 KeyUpdate 消息实现, 以轮换会话密钥.当接收方达到 IL 时, 实现应关闭连接.虽然这些建议是最佳实践, 实现者需要知道, 对构建在 TLS/DTLS 之上的协议来说, 若不引入跨层协调, 实现这些建议并不总是容易.QUIC 中加密层和传输层为支持密钥更新而进行必要协作的示例见 [RFC9001] 第 6 节.一般而言, 应用协议可能因与 TLS/DTLS 的交互更受限而无法模拟该方法.因此, 这些建议不是强制要求.

所有 TLS 1.3 密码套件的 CL 和 IL 值见 [RFC8446] 第 5.5 节.所有 DTLS 1.3 密码套件的对应值见 [RFC9147] 第 4.5.3 节.

对于本文推荐用于 TLS 1.2 和 DTLS 1.2 的所有 AES-GCM 密码套件, 可把对应参数代入 [AEAD-LIMITS] 第 6.1 节中适用于随机且部分隐式 nonce 的不等式来推导 CL, 该 nonce 构造即 TLS 1.2 中使用的构造.虽然所得数值略高于 TLS 1.3 的数值, 但推荐两个版本均使用 2^24.5 条记录的相同限制.

对于推荐用于 DTLS 1.2 的所有 AES-GCM 密码套件, IL, 由上述同一不等式得到, 为 2^28.

4.5. 公钥长度 (Public Key Length)​

使用本文推荐的密码套件时, TLS 握手通常使用两个公钥: 一个用于 Diffie-Hellman 密钥协商, 一个用于服务器认证.如果使用客户端证书, 则会增加第三个公钥.

对于基于模指数 (MODP) Diffie-Hellman 群的密钥交换, 即 "DHE" 密码套件, DH 密钥长度必须至少为 2048 位.

理由: 由于各种原因, 实践中 DH 密钥通常生成长度为 2 的幂, 例如 2^10 = 1024 位、2^11 = 2048 位、2^12 = 4096 位.根据 [RFC3766], 1228 位 DH 密钥大致只等价于 80 位对称密钥, 因此 "DHE" 族密码套件应使用更长密钥.1926 位 DH 密钥大致等价于 100 位对称密钥 [RFC3766].2048 位 DH 密钥等价于 112 位对称密钥, 是撰写本文时 [NIST.SP.800-56A] 最新修订版允许的最小值, 尤其见该文档附录 D.

[RFC3766] 指出, 若修正 The Weizmann Institute Relation Locator (TWIRL) 机器 [TWIRL] 的出现, 1024 位 DH 密钥约产生 61 位等价强度, 2048 位 DH 密钥约产生 92 位等价强度.Logjam 攻击 [Logjam] 进一步表明应避免 1024 位 Diffie-Hellman 参数.

关于 ECDH 密钥, 实现者应参考 "Transport Layer Security (TLS) Parameters" 注册表 [IANA_TLS] 中的 IANA "TLS Supported Groups" 注册表, 该注册表原称 "EC Named Curve Registry", 尤其是其中 "recommended" 群.禁止使用小于 224 位的曲线.该建议与 [NIST.SP.800-56A] 最新修订版一致.

使用 RSA 时, 服务器必须使用公钥模数至少为 2048 位的证书进行认证.此外, 推荐使用 SHA-256 哈希算法, 禁止使用 SHA-1 或 MD5 [RFC9155].更多细节另见 [CAB-Baseline], 撰写本文时当前版本为 1.8.4.客户端必须使用 TLS 1.2 中定义的 "Signature Algorithms" 扩展向服务器表明其请求 SHA-256.对于 TLS 1.3, [RFC8446] 已规定相同要求.

4.6. 截断 HMAC (Truncated HMAC)​

实现禁止使用 [RFC6066] 第 7 节定义的 Truncated HMAC Extension.

理由: 该扩展不适用于上文推荐的 AEAD 密码套件.不过, 它适用于多数其他 TLS 密码套件.[PatersonRS11] 已证明其使用是不安全的.

最后于 更新