跳到主要内容

1. 简介 (Introduction)

Transport Layer Security (TLS) 和 Datagram Transport Layer Security (DTLS) 用于保护通过多种应用协议交换的数据, 包括 HTTP [RFC9112] [RFC9113], IMAP [RFC9051], Post Office Protocol (POP) [STD53], SIP [RFC3261], SMTP [RFC5321] 以及 Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. 这些协议同时使用 TLS 或 DTLS handshake protocol 以及 TLS 或 DTLS record layer. 虽然 TLS handshake protocol 也可以与不同的 record layers 一起用于定义安全传输协议, 最突出的例子是 QUIC [RFC9000], 但这类传输协议并不直接属于本文档范围. 尽管如此, 只要这些协议使用 TLS handshake protocol, 本文中的许多建议仍可能适用.

在 2015 年之前的多年里, 业界已经见证了针对 TLS 和 DTLS 的严重攻击, 包括针对最常用 cipher suites 及其运行模式的攻击. 例如, AES-CBC [RFC3602] 和 RC4 [RFC7465] 两种加密算法曾经共同构成部署最广泛的密码, 都曾在 TLS 上下文中遭受攻击. 关于 2015 年之前已知攻击的详细信息, 见上一版 TLS 建议 [RFC7525] 的配套文档 [RFC7457]. 该文档有助于读者理解本文所给建议背后的理由. 该配套文档没有与本文同步更新. 相反, 更新的攻击以及这些攻击的缓解措施在本文中描述.

TLS 社区以多种方式回应 [RFC7457] 中描述的攻击:

  • 发布了关于使用 TLS 1.2 [RFC5246] 和 DTLS 1.2 [RFC6347] 以及更早协议版本的详细指导. 这些指导包含在原始 [RFC7525] 中, 并大多保留在本修订版本中. 请注意, 自 RFC 7525 于 2015 年发布以来, 这些指导大多已被业界采用.

  • TLS 1.2 之前的版本已被废弃 [RFC8996].

  • 发布了 TLS [RFC8446] 1.3 版, 随后发布了 DTLS [RFC9147] 1.3 版. 这些版本在很大程度上缓解或解决了上述攻击.

实现和部署 TLS 以及基于 TLS 的协议的人需要关于如何安全使用它们的指导. 本文档为已部署服务以及软件实现提供指导, 前提是假设实现者预期其代码会部署在第 5 节定义的环境中. 在部署方面, 本文档面向广泛受众, 即所有希望为其通信增加认证 (无论是单向还是双向), 机密性和数据完整性保护的部署者.

本文中的建议考虑了各种机制的安全性, 技术成熟度和互操作性, 以及撰写时这些机制在实现中的普及程度. 除非明确指出某项建议仅适用于 TLS 或仅适用于 DTLS, 每项建议都同时适用于 TLS 和 DTLS.

本文档试图尽量减少对 TLS 1.2 实现的新指导, 总体方法是鼓励系统迁移到 TLS 1.3. 但是, 这并不总是可行. 新发现的攻击以及生态系统变化, 使得有必要提出一些适用于 TLS 1.2 环境的新要求. 这些要求汇总在附录 A 中.

未来自然仍可能出现攻击, 本文档无法解决这些未来攻击. 强烈建议实现和部署 TLS/DTLS 以及基于 TLS/DTLS 的协议的人关注未来发展. 特别是, 尽管已知量子计算机的出现将对密码原语以及使用这些原语的技术的安全性产生重大影响, 但当前 post-quantum cryptography 仍在发展中, 现在提出建议还为时过早. 一旦相关规范在 IETF 或其他地方标准化, 本文档应更新以反映当时的最佳实践.

如前所述, TLS 1.3 规范解决了本文档列出的许多漏洞. 部署 TLS 1.3 的系统应比 TLS 1.2 或更低版本具有更少漏洞. 因此, 本文档取代 [RFC7525], 其明确目标是鼓励大多数 TLS 1.2 用途迁移到 TLS 1.3.

这些是绝大多数实现和部署场景中使用 TLS 的最低建议, 未认证 TLS 除外 (见第 5 节). 引用本文档的其他规范可以根据其特定情况, 例如用于特定应用协议, 对协议的一个或多个方面提出更严格要求. 在这种情况下, 建议实现者遵循那些更严格要求. 此外, 本文档提供的是下限, 不是上限: 在可行时, 鼓励服务管理员超越实现中可用的最低支持, 以提供尽可能强的安全性. 例如, 基于对现有应用协议部署基础的了解, 以及对安全强度与互操作性之间的成本收益分析, 给定服务提供者可能决定完全禁用 TLS 1.2, 只提供 TLS 1.3.

社区关于各种算法强度和可行攻击的知识可能快速变化, 经验表明, 关于安全的 Best Current Practice (BCP) 文档是某一时间点的陈述. 建议读者查找适用于本文档的任何勘误或更新.

鉴于 [Boeck2016] 攻击, 本文档更新 [RFC5288]. 详情见第 7.2.1 节.

鉴于 [ALPACA] 攻击, 本文档更新 [RFC6066]. 详情见第 3.7 节.

最后于 更新