4.2. RHEL 8 中 TLS 的安全注意事项
在 RHEL 8 中，由于系统范围的加密策略，与加密相关的注意事项大大简化了。DEFAULT 加密策略只允许 TLS 1.2 和 1.3。要允许您的系统使用早期版本的 TLS 来协商连接，您需要选择不使用应用程序中的以下加密策略，或使用 update-crypto-policies 命令切换到 LEGACY 策略。如需更多信息，请参阅 使用系统范围的加密策略。
RHEL 8 中包含的库提供的默认设置足以满足大多数部署的需要。TLS 实现尽可能使用安全算法，而不阻止来自或到旧客户端或服务器的连接。在具有严格安全要求的环境中应用强化设置，在这些环境中，不支持安全算法或协议的旧客户端或服务器不应连接或不允许连接。
强化 TLS 配置的最简单方法是使用 update-crypto-policies --set FUTURE 命令将系统范围的加密策略级别切换到 FUTURE 。
为 LEGACY 加密策略禁用的算法不符合红帽的 RHEL 8 安全愿景，其安全属性不可靠。考虑放弃使用这些算法，而不是重新启用它们。如果您确实决定重新启用它们（例如，为了与旧硬件的互操作性），请将它们视为不安全的，并应用额外的保护措施，例如将其网络交互隔离到单独的网络段。不要在公共网络中使用它们。
如果您决定不遵循 RHEL 系统范围的加密策略，或根据您的设置创建自定义的加密策略，请在自定义配置中对首选协议、密码套件和密钥长度使用以下建议：
4.2.1. 协议
TLS 的最新版本提供了最佳安全机制。除非有充分的理由包含对旧版本的 TLS 的支持，否则请允许您的系统使用至少 TLS 版本 1.2 来协商连接。
请注意，尽管 RHEL 8 支持 TLS 版本 1.3，但 RHEL 8 组件并不完全支持这个协议的所有功能。例如，Apache Web 服务器尚不完全支持可降低连接延迟的 0-RTT(Zero R Trip Time)功能。
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)用来签署您的密钥的哈希功能和密钥同样重要。
其它资源
- RHEL 8 中的系统范围的加密策略
-
您系统上的
update-crypto-policies (8)手册页
