4.2. RHEL 9 中 TLS 的安全注意事项
在 RHEL 9 中，TLS 配置是使用系统范围的加密策略机制执行的。不再支持 1.2 以下的 TLS 版本。DEFAULT、FUTURE 和 LEGACY 加密策略只允许 TLS 1.2 和 1.3。如需更多信息，请参阅 使用系统范围的加密策略。
RHEL 9 中包含的库所提供的默认设置对于大多数部署来说已经足够安全了。TLS 实现尽可能使用安全算法，而不阻止来自或到旧客户端或服务器的连接。在具有严格安全要求的环境中应用强化设置，在这些环境中，不支持安全算法或协议的旧客户端或服务器不应连接或不允许连接。
强化 TLS 配置的最简单方法是使用 update-crypto-policies --set FUTURE 命令将系统范围的加密策略级别切换到 FUTURE 。
为 LEGACY 加密策略禁用的算法不符合红帽的 RHEL 9 安全愿景，其安全属性不可靠。考虑放弃使用这些算法，而不是重新启用它们。如果您确实决定重新启用它们（例如，为了与旧硬件的互操作性），请将它们视为不安全的，并应用额外的保护措施，例如将其网络交互隔离到单独的网络段。不要在公共网络中使用它们。
如果您决定不遵循 RHEL 系统范围的加密策略，或根据您的设置创建自定义的加密策略，请在自定义配置中对首选协议、密码套件和密钥长度使用以下建议：
4.2.1. 协议
TLS 的最新版本提供了最佳安全机制。TLS 1.2 现在是最低版本，即使使用 LEGACY 加密策略也是如此。通过选择不使用加密策略或提供自定义策略，可以重新启用旧协议版本，但不支持生成的配置。
请注意，尽管 RHEL 9 支持 TLS 版本 1.3，但 RHEL 9 组件并不完全支持这个协议的所有功能。例如，Apache Web 服务器尚不完全支持可降低连接延迟的 0-RTT(Zero R Trip Time)功能。
在 FIPS 模式下运行的 RHEL 9.2 及更新的版本强制任何 TLS 1.2 连接都必须使用Extended Master Secret (EMS)扩展(RFC 7627)，因为 FIPS 140-3 标准需要。因此，不支持 EMS 或 TLS 1.3 的旧客户端无法连接到在 FIPS 模式下运行的 RHEL 9 服务器，FIPS 模式下的 RHEL 9 客户端无法连接到只支持没有 EMS 的 TLS 1.2 的服务器。请参阅 使用 Red Hat Enterprise Linux 9.2 强制执行的 TLS 扩展 "Extended Master Secret"
4.2.2. 密码套件
现代、更安全的密码套件应该优先于旧的不安全密码套件。一直禁止 eNULL 和 aNULL 密码套件的使用，它们根本不提供任何加密或身份验证。如果有可能，基于 RC4 或 HMAC-MD5 的密码套件也必须被禁用。这同样适用于所谓的出口密码套件，它们被有意地弱化了，因此很容易被破解。
虽然不会立即变得不安全，但提供安全性少于 128 位的密码套件在它们的短使用期中不应该被考虑。使用 128 位或者更高安全性的算法可以预期在至少数年内不会被破坏，因此我们强烈推荐您使用此算法。请注意，虽然 3DES 密码公告使用 168 位但它们实际只提供了 112 位的安全性。
始终优先使用支持(完美)转发保密(PFS)的密码套件，这样可确保加密数据的机密性，以防服务器密钥被泄露。此规则排除了快速 RSA 密钥交换，但允许使用 ECDHE 和 DHE。在两者中，ECDHE 更快，因此是首选。
您还应该优先选择 AEAD 密码，如 AES-GCM，使用 CBC 模式密码，因为它们不容易受到 padding oracle 攻击的影响。此外，在很多情况下，在 CBC 模式下，AES-GCM 比 AES 快，特别是当硬件具有 AES 加密加速器时。
另请注意，在使用带有 ECDSA 证书的 ECDHE 密钥交换时，事务的速度甚至比纯 RSA 密钥交换要快。为了给旧客户端提供支持，您可以在服务器上安装两对证书和密钥：一对带有 ECDSA 密钥（用于新客户端），另一对带有 RSA 密钥（用于旧密钥）。
4.2.3. 公钥长度
在使用 RSA 密钥时，总是首选使用至少由 SHA-256 签名的 3072 位的密钥长度，对于真实的 128 位安全性来说，这个值已经足够大。
您的系统安全性仅与链中最弱的连接相同。例如，只是一个强大的密码不能保证良好安全性。密钥和证书以及认证机构(CA)用来签署您的密钥的哈希功能和密钥同样重要。
