使用 TLS 保护数据

介绍

本指南面向负责配置其资产内的服务器或客户端的系统管理员。它适用于任何 TLS 服务。

我们提供了涵盖最常见版本和场景的 TLS 安全配置推荐配置文件，并提供了有关禁用旧版本 TLS 中存在的不安全功能的额外指导。

本指南末尾包含有关将 TLS 部署到 Web 和邮件服务器的其他注意事项。

关于 TLS

传输层安全性 (TLS) 是一种为双方之间的数字通信提供安全性的协议。

当服务器和客户端通信时，配置良好的 TLS 可确保第三方无法窃听或篡改任何消息。但是，配置 TLS 可能很困难，如果配置不正确，可能会导致虚假的安全感。

弃用的协议

TLS 协议的前身是安全套接字层 (SSL) 协议，该协议的所有版本均已正式弃用，被视为不安全，不得使用。

同样，TLS 版本 1.1 和 1.0 已被 IETF 正式弃用（RFC 8996），不应再使用。

NCSC 建议使用 TLS 1.1 或 1.0 版本的政府系统升级到 TLS 1.3 或 1.2 版本。

当前版本

在撰写本文时，TLS 的最新版本是 1.3，其设计比以前的版本更安全。

仅建议部署 TLS 1.3 和 1.2 版本。

常规 TLS 配置

建议将本节中的配置文件与系统管理员控制下的所有服务器和客户端中的 TLS 一起使用。

TLS 1.3 和 TLS 1.2 各有两个推荐配置文件。这两个配置文件仅在数字签名算法的选择上有所不同。两者都提供同等的保护，因此可以配置其中一个或两个。

概括

• 应该使用配置了推荐配置文件的TLS 1.3 和/或 TLS 1.2 。

• 如果配置正确，TLS 1.3 和 TLS 1.2 都可以为客户端和服务器之间发送的数据提供强大的保护。TLS 1.3 删除了一些过时的加密技术，使某些攻击变得更加困难，但对 TLS 1.3 的支持可能并不总是可行的（例如对于某些企业设置）。

• 如果需要支持各种各样的客户端，可能需要支持 TLS 1.2 兼容性配置文件。

• 应该禁用 TLS 1.1 和 1.0。

• 必须禁用已知不安全的 TLS 功能。

• 所有服务器和客户端都应使用最新的软件版本。如果不及时修补，实施问题可能会引入可被利用的漏洞。

TLS 1.3 配置

TLS 1.3 引入了一些重大变化。它使用与早期 TLS 版本不同的密码套件定义，并且具有不同的配置选项。

某些实现将 TLS 1.3 配置与以前的 TLS 版本分开。请查阅您的实现文档以确定如何配置特定于 TLS 1.3 的选项。

TLS 1.3 规范仅支持强加密算法。不过，NCSC 建议使用以下配置文件：

TLS 1.3 的推荐配置文件

TLS 1.2 配置

当客户端和服务器实现支持 AES-GCM 时，应使用下面的推荐配置文件。

如果不支持 AES-GCM，则可以使用 TLS 1.2 兼容性配置文件。

TLS 1.2 的推荐配置文件

TLS 1.2 兼容性配置文件

旧版本

TLS 1.1 和 1.0 的旧版配置文件

TLS 1.1 和 1.0 版本不支持当前的经过身份验证的加密密码套件，并且存在其他已知漏洞。这些旧版本已被 IETF（RFC 8996）正式弃用，不应再使用。

对于使用弃用 TLS 版本或密码套件的任何政府系统，应制定有时限的迁移计划。如果无法做到这一点，系统所有者应向 NCSC 寻求建议。

以下旧版配置文件是针对无法禁用 TLS 版本 1.1 和 1.0 的用例定义的。

第三方服务

当 TLS 服务托管在第三方提供商（例如内容分发网络 (CDN)）的基础设施上时，TLS 配置可能不受数据所有者的直接控制。在这种情况下，服务提供商通常会允许数据所有者选择一项政策，该政策指定允许使用哪些 TLS 版本和密码套件。

数据所有者应选择最严格的可用政策。此政策应根据需要启用 TLS 1.3 和/或 TLS 1.2，并应包括上述针对 TLS 1.3 和/或 TLS 1.2 的推荐配置文件。

启用旧版 TLS 版本和密码套件的策略仅应在绝对必要时使用，并且仅针对需要它的服务，而不是针对所有服务。

避免已知的不安全因素

旧版 TLS（TLS 1.2 及以下版本）包含一些安全性较弱的功能和加密组件。在大多数情况下，只有当客户端和服务器都支持这些功能和组件时，它们才会在连接中协商。

使用最新的软件将减少使用不安全功能的机会。为了避免一些最常见的漏洞，您必须确保在您使用的 TLS 实现中禁用以下功能和组件：

• 禁用 TLS 不安全重新协商（通过禁用重新协商或启用重新协商指示扩展，如RFC 5746中所述）。

• 禁用 TLS 不安全协议降级（通过支持 Fallback Signaling Cipher Suite Value，如RFC 7507中所述）。 请注意，仅当您支持 TLS 1.1 或更早版本时才需要执行此操作。

• 禁用 TLS 记录压缩（如RFC 5246 第 6.2.2 节所述）。

• 通过确保禁用 EXPORT 密码来禁用导出密钥生成（如RFC 2246 第 6.3.1 节中所述）。

• 禁用对 SSL 2 的支持，因为它可用于攻击更强的连接。

TLS 1.3 提供了一种可选的零往返模式，称为 0-RTT，允许客户端在完整的 TLS 握手完成之前，在 TLS 会话的早期发送数据。如果使用不当，此模式会导致重放攻击。根据使用 TLS 的应用程序协议，这可能会导致安全漏洞。

一些基于 TLS 1.3 构建的应用程序协议包含针对尝试重放攻击的缓解措施，并且可以安全地使用 0-RTT 模式。除非您使用的应用程序协议和软件可以缓解这些风险，否则您不应启用 0-RTT 模式。

选择证书颁发机构

TLS 使用 X.509v3 证书以加密方式验证通信一方或双方提供的身份。

如果连接方可以验证提供给它的证书是由它信任的证书颁发机构 (CA) 颁发的，那么就可以建立安全通信。因此，选择一个受到可能连接到您的服务的人员广泛信任的 CA 非常重要。

如果选择不太常见的 CA，则您的服务提供的证书可能无法由连接方验证，并且另一方可能选择不继续会话。

为了验证服务器提供的证书，客户端可以使用其自己的受信任根 CA 存储，也可以参考操作系统信任的 CA。由于没有通用的受信任 CA 列表，因此您需要在预期连接到您的服务的客户端中研究对所选 CA 的支持情况。

如果组织管理自己的内部 CA，并且 TLS 服务在内部托管，并且仅由信任内部 CA 的托管客户端托管，则使用由该内部 CA 颁发的证书可能是合适的。NCSC为内部 CA 的操作提供了指导。

许多云提供商都向客户提供 CA 服务，客户可从中获取由公共 CA 颁发的用于 TLS 的证书，这些证书由云提供商控制。如果您正在使用云服务，请查看相关文档以获取有关如何从这些服务获取证书的说明。

如果您正在管理自己的 TLS 服务，并希望这些服务被未知客户端使用和信任，则您的服务必须使用来自公共 CA 的证书。有许多 CA，它们被客户端信任库接受的程度、技术支持和颁发方法各不相同。您需要研究哪个 CA 最能满足您的需求。

限制发行

当您选择了 CA 后，您应该发布 DNS 证书颁发机构授权 (CAA) 记录，以将您的域的证书颁发限制为您选择的 CA。

这有助于降低其他 CA 颁发未经授权证书的风险。您的 CA 应提供有关如何填充这些记录的详细信息。

吊销证书

您应该确保您有办法撤销您服务的受损证书。

您选择的 CA 应该提供一种请求撤销的方法，以及一种用于分发撤销证书通知的适当机制，例如证书撤销列表 (CRL) 或在线证书状态协议 (OCSP)。

这将允许验证方检查 CRL，或使用 OCSP 来接收证书撤销通知，并且不再认为它们是受信任的。

请求证书

为了获得 CA 签名的 X.509v3 证书，您通常会生成自己的私钥，并向 CA 发送证书签名请求 (CSR) 进行签名，从而保证私钥的机密性。这可以是手动过程，也可以通过各种工具自动完成。

您可以为私钥和签名请求选择多个参数。根据上述配置文件，我们建议使用以下参数来生成椭圆曲线和 RSA 密钥：

• ECDSA-256 与 P-256 曲线上的 SHA256，

• 带有 SHA256 的 2048 位 RSA。

您应该调查在硬件安全模块 (HSM) 中存储私钥是否适合您的部署。

续订证书

在撰写本文时，公共 CA 颁发的证书的最大有效期为 13 个月，可使用一年，续期为一个月。强烈建议系统管理流程考虑到这一点，并在证书到期前至少一个月续订证书。

一些 CA 支持使用各种使用证书管理协议的工具，这些工具允许自动续订证书而无需管理员干预。这些工具包括 ACME、CMPv2、SCEP 或 Windows 客户端证书注册协议。应尽可能使用这些工具，以避免证书意外过期，这可能会导致 TLS 服务停机。

如果 CA 颁发的是短期证书，则建议使用自动续订功能，以确保 TLS 服务始终拥有有效的证书。您应该定期查看自动续订软件的日志，以确保续订过程正常运行。您还应该随时了解所选 CA 的最新动态，以确保不会发生任何可能导致自动续订过程无法续订证书的变更。

监控

您可能希望考虑监控证书透明度 (CT) 日志。这将允许您查找已颁发给您的域（包括子域）的证书，从而检测 CA 错误颁发的证书或为您的域颁发的意外证书。

您可以使用公开可用的服务手动监控 CT 日志，或者您可以订阅代表您执行监控和警报的商业产品。

为 Web 服务器部署 TLS

Web 服务器应使用上述部分所述的 TLS。但是，您应使用一些 HTTPS 特定功能来提高 Web 服务或网站的安全性：

• 仅使用 HTTPS 发布服务。

• 将未加密的 HTTP 请求重定向到 HTTPS 版本。

• 使用HTTP 严格传输安全 (HSTS)强制到您的 Web 服务器的所有连接使用 HTTPS 而不是未加密的 HTTP，并预加载您的 HSTS 策略（有关更多详细信息，请参阅hstspreload.org ）。

• 在您的内容安全策略中使用upgrade-insecure-requests 指令，强制使用 HTTPS 而不是未加密的 HTTP 加载您网站上的所有内容（包括第三方内容）。

为邮件服务器部署 TLS

此设置下的 TLS 可能比其他场景更复杂，因此应格外小心以防止出现问题，例如以纯文本发送邮件，或邮件（悄悄地）无法送达。

为了处理端口 25 上使用 SMTP STARTTLS 与其他邮件传输代理 (MTA) 的连接，邮件服务器应使用上述部分所述的 TLS。

请注意，协商 TLS 会话失败可能会导致电子邮件回退到纯文本形式发送。为了降低发生这种情况的可能性，您应尝试使用 TLS 1.3 和 1.2 的推荐配置文件以及 TLS 1.2 的兼容性配置文件来最大限度地提高与其他 MTA 的兼容性。您应该检查邮件服务器日志，以确保您的 TLS 配置不会导致连接回退到无 TLS，因为 TLS 配置文件非常严格。

为了使用 IMAP、POP3 和 SMTP 提交等协议通过邮件用户代理 (MUA) 处理与最终用户的连接，邮件服务器应使用上文所述 TLS 以及 TLS 1.3 和 1.2 的推荐配置文件。

根据RFC 8314，不再建议使用 STARTTLS 进行最终用户和邮件服务之间的通信。相反，应使用“隐式 TLS”，即在建立连接后立即启动 TLS 会话。

例如，对于 IMAP，这意味着使用专用的 IMAPS TCP/993 端口，而不是 IMAP TCP/143 端口上的 STARTTLS。

除了此 TLS 指南之外，您还应查阅有关电子邮件安全和反欺骗的 NCSC 指南。

或者，您可能希望考虑支持以下新兴标准，以使电子邮件的 TLS 更加明显和强大：

• 部署邮件传输代理严格传输安全 (MTA-STS)，强制支持 MTA 仅使用 TLS 传递邮件。您应该先在测试模式下部署，然后再转到强制模式，以确保在出现配置错误时不会发生邮件传递丢失。

• 部署 SMTP TLS 报告 (TLS-RPT)（如RFC 8460中所述），以允许支持 MTA 向邮件服务器管理员报告 TLS 问题。如果部署 MTA-STS，强烈建议这样做，因为它可以对阻止邮件投递的问题发出警报。

需要注意的是，对于实施这些标准的 MTA，邮件服务器证书的验证将更加严格。一旦激活 MTA-STS，邮件服务器证书就需要与邮件服务器对应的 MX 记录中列出的主机名相匹配，并且证书必须链接到发件人信任的 CA。

测试 Web 和邮件服务器

鉴于 TLS 可用的配置选项范围很广，我们建议您通过运行自动扫描定期测试您的 Web 服务器和邮件服务器的配置。

NCSC 为公共部门的网站和邮件服务器所有者提供Web 检查和邮件检查服务。这将检查一系列潜在的安全问题，包括 TLS 配置。对于私营部门，有各种免费或商业工具可帮助您测试 Web 或邮件服务器的 TLS 配置。

这些扫描将识别最常见的问题和配置问题。它们不能替代对您的服务进行熟练的渗透测试，但如果你已经使用过这些工具来帮助识别和缓解常见问题，那么渗透测试人员将有更多的时间来确保你的服务中没有更微妙或独特的缺陷。

请注意，虽然其他人可以测试您安全接收电子邮件的能力，但如果没有您的合作，其他人则无法测试您的服务安全发送电子邮件的能力。您必须将电子邮件发送到测试服务。