解决 TLS 1.0 问题，第 2 版

本文档提供了有关如何快速识别和删除基于 Microsoft 操作系统的软件中的传输层安全性 （TLS） 协议版本 1.0 依赖项的最新指南，并跟进Microsoft提供的产品更改和新功能的详细信息，以保护自己的客户和联机服务。 它旨在用作将迁移计划构建到 TLS 1.2+ 网络环境的起点。 虽然此处讨论的解决方案可能会延续和帮助删除非Microsoft操作系统或加密库中的 TLS 1.0 用法，但它们不是本文档的焦点。

TLS 1.0 是 1999 年首次定义的安全协议，用于通过计算机网络建立加密通道。 自 Windows XP/Server 2003 以来，Microsoft支持此协议。 尽管新式 OS 不再使用默认安全协议，但 TLS 1.0 仍支持向后兼容。 不断演变的法规要求以及 TLS 1.0 中的新安全漏洞为公司提供了完全禁用 TLS 1.0 的激励措施。

Microsoft建议客户在环境中删除 TLS 1.0 依赖项并在操作系统级别禁用 TLS 1.0，从而提前解决此问题。 鉴于软件行业支持 TLS 1.0 的时间长度，强烈建议任何 TLS 1.0 弃用计划包括以下内容：

• 用于查找/修复 TLS 1.0 或更高版本安全协议的硬编码实例的代码分析。

• 网络终结点扫描和流量分析，以使用 TLS 1.0 或更早的协议标识操作系统。

• 通过禁用 TLS 1.0 的整个应用程序堆栈进行完全回归测试。

• 将旧操作系统和开发库/框架迁移到默认情况下能够协商 TLS 1.2 的版本。

• 企业在所用操作系统之间进行兼容性测试，以识别任何 TLS 1.2 支持问题。

• 与你自己的业务合作伙伴和客户进行协调，以通知他们你已弃用 TLS 1.0。

• 了解禁用 TLS 1.0 后，哪些客户端可能无法再连接到服务器。

本文档的目标是提供建议，这有助于删除技术阻止程序以禁用 TLS 1.0，同时提高对此更改对你自己的客户的影响的可见性。 完成此类调查有助于降低 TLS 1.0 中下一个安全漏洞的业务影响。 出于本文档的目的，对弃用 TLS 1.0 的引用还包括 TLS 1.1。

企业软件开发人员需要采用更多未来安全敏捷解决方案（也称为加密敏捷性），以应对未来的安全协议泄露。 虽然本文档提出了用于消除 TLS 硬编码的敏捷解决方案，但更广泛的 Crypto Agility 解决方案超出了本文档的范围。

Microsoft TLS 1.0 实现的当前状态

Microsoft的 TLS 1.0 实现 没有已知的安全漏洞。 由于将来 协议降级攻击 和其他与 Microsoft 实现无关的 TLS 1.0 漏洞的可能性，因此建议尽可能去除对低于 TLS 1.2 的所有安全协议的依赖（TLS 1.1/1.0/SSLv3/SSLv2）。

在规划此迁移到 TLS 1.2+ 时，开发人员和系统管理员应了解其员工和合作伙伴开发的应用程序中的协议版本硬编码的可能性。 此处的硬编码意味着 TLS 版本被固定在一个过时且安全性低于新版本的版本上。 如果不修改有问题的程序，则不能使用比硬编码版本更新的 TLS 版本。 如果没有源代码更改和软件更新部署，无法解决此类问题。 为了测试和支持性，协议版本硬编码在过去很常见，因为许多不同的浏览器和操作系统拥有不同的 TLS 支持级别。

Windows 中支持的 TLS 版本

许多操作系统具有过时的 TLS 版本默认值或需要考虑的支持上限。

图 1：OS 版本支持的安全协议

Windows 操作系统	SSLv2	SSLv3	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Windows Vista	已启用	已启用	已启用	不支持	不支持	不支持
Windows Server 2008	已启用	已启用	已启用	禁用*	禁用*	不支持
Windows 7 （WS2008 R2）	已启用	已启用	已启用	禁用*	禁用*	不支持
Windows 8 （WS2012）	已禁用	已启用	已启用	已启用	已启用	不支持
Windows 8.1 （WS2012 R2）	已禁用	已启用	已启用	已启用	已启用	不支持
Windows 10操作系统	已禁用	已启用	已启用	已启用	已启用	不支持
Windows 11	已禁用	已启用	已启用	已启用	已启用	已启用
Windows Server 2016	不支持	已禁用	已启用	已启用	已启用	不支持
Windows Server 2016	不支持	已禁用	已启用	已启用	已启用	不支持
Windows Server 2019	不支持	已禁用	已启用	已启用	已启用	不支持
Windows Server 2019 GS 版本	不支持	已禁用	已禁用	已禁用	已启用	不支持
Windows Server 2022	不支持	已禁用	已禁用	已禁用	已启用	已启用

Windows Server 2019 GS 版本Microsoft SDL 兼容，TLS 1.2 仅具有受限的密码套件集。

Windows Server 2022 版本Microsoft SDL 兼容、TLS 1.2 和 TLS 1.3，仅具有一组受限的密码套件。

可以通过此可选 Windows 更新包在 Windows Server 2008 上启用 TLS 1.1/1.2。

有关在 IE/Edge 中弃用 TLS 1.0/1.1 的详细信息，请参阅 在 Microsoft Edge 和 Internet Explorer 11 中现代化 TLS 连接，即将影响 Microsoft Edge 站点兼容性的更改 以及 在新 Edge 浏览器中禁用 TLS/1.0 和 TLS/1.1。

通过引用 Qualys SSL 实验室的握手模拟，快速确定连接到联机服务时各种客户端将请求哪些 TLS 版本。 此模拟涵盖制造商之间的客户端 OS/浏览器组合。 有关在连接到 www.microsoft.com时由各种模拟客户端 OS/浏览器组合协商的 TLS 协议版本的详细示例，请参阅本文档末尾的附录 A。

如果尚未完成，强烈建议对企业、客户和合作伙伴使用的操作系统进行清单（后两种通过外展/通信或至少 HTTP User-Agent 字符串收集）。 可以通过企业网络边缘的流量分析进一步补充此清单。 在这种情况下，流量分析将会生成连接到你们服务的客户/合作伙伴成功协商好的 TLS 版本，但流量本身仍然保持加密。

Microsoft的工程改进来消除 TLS 1.0 依赖项

自本文档的 v1 版本以来，Microsoft提供了许多软件更新和新功能，以支持 TLS 1.0 弃用。 这些包括：

• IIS 自定义日志记录 ，用于关联客户端 IP/用户代理字符串、服务 URI、TLS 协议版本和密码套件。

  • 通过此日志记录，管理员最终可以量化客户对弱 TLS 的暴露。

• SecureScore - 为了帮助 Office 365 租户管理员识别其弱 TLS 使用情况，已建立 SecureScore 门户，以便在 2018 年 10 月 TLS 1.0 在 Office 365 中停止支持时共享此信息。

  • 此门户为 Office 365 租户管理员提供了他们向可能不知道自己的 TLS 1.0 依赖项的客户伸出所需的宝贵信息。

  • 有关详细信息，请访问 https://securescore.microsoft.com/。

• .Net Framework 更新以消除应用级硬编码并防止框架继承的 TLS 1.0 依赖项。

• 开发人员指南和软件更新已发布，可帮助客户识别和消除弱 TLS 上的 .Net 依赖项： 使用 .NET Framework 的传输层安全性（TLS）最佳做法

  • FYI：面向 .NET 4.5 或更低版本的所有应用都可能需要修改才能支持 TLS 1.2。

• TLS 1.2 已回移植到 Windows Server 2008 SP2 和 XP POSReady 2009 ，以帮助客户承担旧义务。

• 2019 年初将发布更多公告，并在本文档的后续更新中传达。

在代码中查找和修复 TLS 1.0 依赖项

对于使用 Windows OS 提供的加密库和安全协议的产品，以下步骤应有助于识别应用程序中任何硬编码的 TLS 1.0 用法：

1. 标识 AcquireCredentialsHandle（） 的所有实例。 这有助于审阅者更容易靠近可能硬编码 TLS 的代码块。

2. 查看任何 SecPkgContext_SupportedProtocols 和 SecPkgContext_ConnectionInfo 结构的硬编码 TLS 实例。

3. 在本机代码中，将 grbitEnabledProtocols 的任何非零分配设置为零。 这样，操作系统就可以使用其默认 TLS 版本。

4. 如启用FIPS 模式，请禁用它，因为可能与本文档中显式禁用 TLS 1.0/1.1 所需的设置产生冲突。 有关详细信息，请参阅 附录 B 。

5. 使用 Server 2012 或更高版本上托管的 WinHTTP 更新和重新编译任何应用程序。

   1. 托管应用 - 根据最新的 .NET Framework 版本重新生成和重新定目标

   2. 应用程序必须添加代码才能通过 WinHttpSetOption 支持 TLS 1.2

6. 若要涵盖所有基数，请扫描源代码和联机服务配置文件，了解以下模式，这些模式对应于 TLS 硬编码中常用的枚举类型值：

   1. SecurityProtocolType

   2. SSLv2、SSLv23、SSLv3、TLS1、TLS 10、TLS11

   3. WINHTTP_FLAG_SECURE_PROTOCOL_

   4. SP_PROT_

   5. NSStreamSocketSecurityLevel

   6. PROTOCOL_SSL或PROTOCOL_TLS

在上述所有情况下，建议的解决方案是删除硬编码协议版本选择并延迟操作系统默认值。 如果您正使用 DevSkim，请点击此处 查看涵盖上述检查的规则，您可以将这些规则运用于自己的代码。

更新 Windows PowerShell 脚本或相关的注册表设置

Windows PowerShell 使用 .NET Framework 4.5，其中不包括 TLS 1.2 作为可用协议。 若要解决此问题，有两种解决方案可用：

1. 修改相关脚本以包括以下内容：

   [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
   

2. 将系统范围的注册表项（例如通过组策略）添加到需要从 .NET 应用建立 TLS 1.2 连接的任何计算机。 这将导致 .NET 使用将 TLS 1.2 添加为可用协议的“系统默认”TLS 版本，并允许脚本在 OS 支持它们时使用未来的 TLS 版本。 （例如 TLS 1.3）

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg：64

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg：32

解决方案（1）和（2）是相互排斥的，这意味着它们不需要一起实现。

使用最新的 .Net Framework 版本重新生成/重新定目标托管应用程序

使用 4.7 之前的 .NET Framework 版本的应用程序可能会限制对 TLS 1.0 的支持，而不管基础 OS 默认值如何。 有关详细信息，请参阅下图和 .NET Framework 的传输层安全性（TLS）最佳做法 。

SystemDefaultTLSVersion 优先于应用级别指定的 TLS 版本。 建议的最佳做法是始终遵循 OS 默认 TLS 版本。 它也是唯一允许应用利用未来 TLS 1.3 支持的加密敏捷解决方案。

如果您的目标是使用较旧版本的 .NET Framework（如 4.5.2 或 3.5），那么默认情况下，您的应用程序将使用不推荐的较旧协议（如 SSL 3.0 或 TLS 1.0）。 强烈建议升级到 .NET Framework 4.6 等较新版本的 .NET Framework，或为“UseStrongCrypto”设置相应的注册表项。

使用 TLS 1.2+ 进行测试

为了检测协议协商错误以及与企业中其他操作系统的兼容性，建议按照上述部分中的修复措施对产品进行回归测试。

• 此回归测试中最常见的问题是 TLS 协商失败，原因是来自不支持 TLS 1.2 的操作系统或浏览器的客户端连接尝试。

  • 例如，Vista 客户端无法与配置为 TLS 1.2+ 的服务器协商 TLS，因为 Vista 支持的最大 TLS 版本为 1.0。 应在 TLS 1.2+ 环境中升级或停用该客户端。

• 使用基于证书的相互 TLS 身份验证的产品可能需要额外的回归测试，因为与 TLS 1.0 关联的证书选择代码的表达力低于 TLS 1.2。

  • 如果产品使用来自非标准证书位置（不是 Windows 中标准命名的证书存储）的证书进行 MTLS 配置，则可能需要更新代码以确保正确获取证书。

• 应审查服务相互依赖性，了解问题点。

  • 与 3^{个 rd} 方服务互操作的任何服务都应对这些 3^{个 rd} 方进行额外的互操作测试。

  • 任何正在使用的非 Windows 应用程序或服务器操作系统都需要调查/确认它们是否支持 TLS 1.2。 扫描是确定这一点的最简单方法。

用于在联机服务中测试这些更改的简单蓝图包括：

1. 对生产环境系统进行扫描，以确定不支持 TLS 1.2 的操作系统。

2. 扫描源代码和在线服务配置文件中硬编码的 TLS，如“在代码中查找和修复 TLS 1.0 依赖项”中所述。

3. 根据需要更新/重新编译应用程序：

   1. 管理应用

      1. 根据最新的 .NET Framework 版本重新生成。

      2. 验证 SSLProtocols 枚举的任何用法是否设置为 SSLProtocols.None，以便使用 OS 默认设置。

   2. WinHTTP 应用 - 使用 WinHttpSetOption 重新生成以支持 TLS 1.2

4. 在预生产或过渡环境中开始测试，并通过注册表禁用所有早于 TLS 1.2 的安全协议。

5. 修复在测试中遇到 TLS 硬编码的任何剩余实例。 重新部署软件并执行新的回归测试运行。

通知合作伙伴有关您的 TLS 1.0 弃用计划

解决 TLS 硬编码并完成操作系统/开发框架更新后，如果选择弃用 TLS 1.0，则必须与客户和合作伙伴协调：

• 早期合作伙伴/客户外展对于成功的 TLS 1.0 弃用推出至关重要。 至少这应包括博客文章、白皮书或其他 Web 内容。

• 合作伙伴都需要通过上述部分所述的操作系统/代码扫描/回归测试计划评估自己的 TLS 1.2 就绪情况。

结束语

删除 TLS 1.0 依赖项是一个复杂的问题，需要进行端到端的处理。 Microsoft和行业合作伙伴今天正在对此采取行动，以确保我们的整个产品堆栈在默认情况下更安全，从 OS 组件和开发框架到基于它们构建的应用程序/服务。 遵循本文档中的建议将有助于企业制定正确的课程图表，并了解预期存在哪些挑战。 它还将帮助你的客户为过渡做好准备。

附录 A：不同客户端连接到 www.microsoft.com 由 SSLLabs.com 提供的握手模拟

附录 B：在保留 FIPS 模式时弃用 TLS 1.0/1.1

如果网络需要 FIPS 模式，但还需要弃用 TLS 1.0/1.1，请执行以下步骤：

1. 通过在注册表中将不需要的 TLS 版本的“Enabled”设置为零来配置 TLS 版本。

2. 通过组策略禁用椭圆曲线 25519（仅限服务器 2016）。

3. 使用相关 FIPS 发布不允许的算法禁用任何密码套件。 对于 Server 2016（假设默认设置有效），这意味着禁用 RC4、PSK 和 NULL 密码。

参与者/感谢

马克·卡特赖特
布莱恩·沙利文
帕特里克·琼格斯
迈克尔·斯科维塔
托尼·赖斯
大卫·勒布兰克
莫蒂默·库克
丹尼尔·索默菲尔德
安德烈·波波夫
美智子·肖特
贾斯汀·伯克
州长马哈拉杰
布拉德·特纳
西恩·史蒂文森