跳到主要内容

4.2 Recommended Cipher Suites (推荐的密码套件)

鉴于上述考虑, 建议实现和部署以下密码套件:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

这些密码套件仅在 TLS 1.2 中受支持, 因为它们是认证加密 (Authenticated Encryption with Associated Data, AEAD) 算法 [RFC5116]。

通常, 为了优先使用这些套件, 需要在服务器软件中明确配置套件的顺序。(有关有用的部署指南, 请参阅 [BETTERCRYPTO], 但请注意, 其建议在某些细节上与当前文档有所不同。) 如果服务器软件实现默认情况下就优先使用这些套件, 那将是理想的。

一些设备对 AES-CCM 有硬件支持, 但不支持 AES-GCM, 因此它们无法遵循上述关于密码套件的建议。甚至有些设备根本不支持公钥密码学, 但它们完全超出了范围。

4.2.1 Implementation Details (实现细节)​

客户端应该将 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 作为对任何服务器的第一个提议, 除非它们事先知道服务器无法响应 TLS 1.2 client_hello 消息。

服务器必须优先选择这个密码套件而不是较弱的密码套件, 只要它被提议, 即使它不是第一个提议。

客户端当然可以自由提供更强的密码套件, 例如使用 AES-256; 当它们这样做时, 服务器应该优先选择更强的密码套件, 除非有令人信服的理由 (例如, 性能严重降低) 选择其他方式。

本文档不改变 TLS 规定的强制实现 TLS 密码套件。为了最大化互操作性, RFC 5246 要求实现 TLS_RSA_WITH_AES_128_CBC_SHA 密码套件, 该密码套件明显弱于此处推荐的密码套件。(GCM 模式不会受到相同的弱点影响, 这是由 TLS 中 MAC-then-Encrypt 的顺序导致的 [Krawczyk2001], 因为它使用 AEAD 操作模式。) 实现者在部署 TLS_RSA_WITH_AES_128_CBC_SHA 密码套件时应考虑互操作性收益与安全性损失之间的权衡。其他应用协议将其他密码套件指定为强制实现 (mandatory to implement, MTI)。

请注意, TLS 1.2 的某些配置文件使用不同的密码套件。例如, [RFC6460] 定义了一个使用 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 和 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 密码套件的配置文件。

[RFC4492] 允许客户端和服务器协商 ECDH 参数 (曲线)。客户端和服务器都应该包含 "支持的椭圆曲线" (Supported Elliptic Curves) 扩展 [RFC4492]。为了互操作性, 客户端和服务器应该支持 NIST P-256 (secp256r1) 曲线 [RFC4492]。此外, 客户端应该发送一个包含单个元素 "uncompressed" 的 ec_point_formats 扩展。

最后于 更新