1. Introduction (简介)

传输层安全性 (Transport Layer Security, TLS) [RFC5246] 和数据报传输层安全性 (Datagram Transport Layer Security, DTLS) [RFC6347] 被广泛用于保护通过应用协议交换的数据, 例如 HTTP, SMTP, IMAP, POP, SIP 和 XMPP。在过去几年中, 出现了几次针对 TLS 的严重攻击, 包括针对其最常用的密码套件及其操作模式的攻击。例如, AES-CBC [RFC3602] 和 RC4 [RFC7465] 加密算法是最广泛部署的密码, 但它们在 TLS 的上下文中都受到了攻击。配套文档 [RFC7457] 提供了关于这些攻击的详细信息, 并将帮助读者理解这里提供的建议背后的理由。

由于这些攻击, 那些实现和部署 TLS 和 DTLS 的人需要关于如何安全使用 TLS 的更新指导。本文档为已部署的服务以及软件实现提供指导, 假设实现者期望其代码部署在第 5 节中定义的环境中。实际上, 本文档呼吁部署已广泛实现但尚未广泛部署的算法。关于部署, 本文档针对广泛的受众 -- 即所有希望为其通信添加身份验证 (无论是单向还是双向), 机密性和数据完整性保护的部署者。

此处的建议考虑了各种机制的安全性, 它们的技术成熟度和互操作性, 以及它们在编写时在实现中的普及程度。除非明确指出某项建议仅适用于 TLS 或仅适用于 DTLS, 否则每项建议都适用于 TLS 和 DTLS 两者。

预计 TLS 1.3 规范将解决本文档中列出的许多漏洞。部署 TLS 1.3 的系统应该比 TLS 1.2 或更低版本具有更少的漏洞。本文档可能会在 TLS 1.3 获得显著部署后进行更新。

这些是在绝大多数实现和部署场景中使用 TLS 的最低建议, 但未经身份验证的 TLS 除外 (参见第 5 节)。引用本文档的其他规范可以根据其特定情况 (例如, 用于特定应用协议) 对协议的一个或多个方面有更严格的要求; 在这种情况下, 建议实现者遵守这些更严格的要求。此外, 本文档提供了一个底线, 而不是上限, 因此总是允许使用更强的选项 (例如, 取决于对加密强度与计算负载的重要性的不同评估)。

关于各种算法强度和可行攻击的社区知识可能会快速变化, 经验表明, 关于安全性的最佳当前实践 (Best Current Practice, BCP) 文档是一个时间点声明。建议读者查找适用于本文档的任何勘误表或更新。