由于 Windows 10 计算机运行 RDP，TrustWave 的漏洞扫描程序扫描失败：
块大小为 64 位的分组密码算法（如 DES 和 3DES）生日攻击称为 Sweet32 (CVE-2016-2183)
注意：在运行 RDP（远程桌面协议）的 Windows 7/10 系统上，应禁用的易受攻击的密码标记为“TLS_RSA_WITH_3DES_EDE_CBC_SHA”。
使用 IIS Crypto（由 Nartac 提供），我尝试应用“最佳实践”模板以及 PCI 3.1 模板，但它们都包含不安全的密码（TLS_RSA_WITH_3DES_EDE_CBC_SHA）：
如果我禁用此密码，RDP从这台计算机对许多 Windows 工作站停止工作（对某些 2008 R2 和 2012 R2 服务器仍可工作）。RDP 客户端仅给出“发生内部错误”和事件日志：
创建 TLS 客户端凭据时发生致命错误。内部错误状态为 10013。
我检查了其中一台服务器的服务器事件日志，看到以下两条消息
从远程客户端应用程序收到 TLS 1.2 连接请求，但服务器不支持客户端应用程序支持的任何密码套件。SSL 连接请求失败。
生成了以下致命警报：40。内部错误状态为 1205。
如何在不破坏传出 RDP 的情况下修复安全漏洞？
或者，如果上述方法不可行，我可以在每个无法再连接的 RDP 主机上做些什么来处理该问题？
---更新＃1---
在 Windows 10 计算机上禁用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 后，我尝试连接多个 RDP 主机（其中一半失败，并显示“内部错误...”）。因此，我将其中一个主机与我之前使用的 RDP 主机进行了比较。能连接到我不能连接到。两者都是 2008 R2。两者都具有相同的 RDP 版本（6.3.9600，支持 RDP 协议 8.1）。
我使用 IIS Crypto 在当前设置上执行“保存模板”来比较 TLS 协议和密码，以便可以比较模板文件。它们是相同的！因此，无论问题是什么，似乎都不是主机上缺少芯片套件的问题。以下是 Beyond Compare 对文件的屏幕截图：
两个 RDP 主机之间可能存在哪些差异导致此问题以及如何解决此问题？
答案1
IIS Crypto 有设置服务器端（传入）和客户端（传出）选项的选项。为了实现兼容性，您需要在客户端启用一些密码。
为了做你想做的事，我个人会采取以下措施：
- 应用 3.1 模板
- 保持所有密码套件处于启用状态
- 适用于客户端和服务器（复选框勾选）。
- 点击“应用”保存更改
如果需要的话，请在此处重新启动（并且您可以物理访问该机器）。
- 应用 3.1 模板
- 保持所有密码套件处于启用状态
- 应用于服务器（取消选中复选框）。
- 取消选中 3DES 选项
此处重新启动应该会导致正确的最终状态。
实际上，您只想禁用 3DES 入站，但仍允许出站使用该密码套件。
答案2
编辑（2018-09-26）：我发现在 2012R2 上禁用 3DES 不会破坏 RDP，但在 2008 R2 上会破坏。支持的选项似乎在内核之间有所不同。
我将从 TechNet 分享我的答案线但首先要说的是：
Serverfault结论：很可能系统之间存在其他差异。您正在连接不同的操作系统版本，一个系统启用了 FIPS，而另一个系统没有，或者您在 下设置了不同的密码限制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers。我肯定会在系统上启用 SCHANNEL 日志记录做确定正在使用哪种密码。如果您能以某种方式让 RDP 与替代密码配合使用，我将非常乐意收到您的回复。
帖子副本：
我们让它工作了！
显然，2008 和 2012 存在语法问题，并且 2008/7 需要尾随 /168。2012/8.1/10 则不需要。
2008 年的密钥如下所示：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/1682012 年的密钥如下：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
我可以确认使用“三重 DES 168/168”不会禁用系统上的 3DES。您可以使用协议扫描器（如 Nessus）或启用 SCHANNEL 日志记录来亲自证明这一点：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007然后，您将在系统日志中看到相关事件，例如：
SSL 客户端握手已成功完成。协商的加密参数如下。
协议：TLS 1.0 密码套件：0x2f 交换强度：1024
对我来说，结果是 0xa，Google 将其显示为 TLS_RSA_WITH_3DES_EDE_CBC_SHA。
当我使用“三重 DES 168”（不带 /168）时，系统事件 ID 36880 不会出现，并且 RDP 会话被阻止。
根据文章：系统加密：使用符合 FIPS 标准的算法进行加密、哈希和签名
远程桌面服务 (RDS) 对于加密远程桌面服务网络通信，此策略设置仅支持三重 DES 加密算法。
根据文章：“系统加密：使用符合 FIPS 标准的算法进行加密、哈希和签名”安全设置在 Windows XP 和更高版本的 Windows 中的效果
此设置还会影响 Windows Server 2003 及更高版本的 Windows 中的终端服务。影响取决于是否使用 TLS 进行服务器身份验证。
如果使用 TLS 进行服务器身份验证，则此设置仅导致使用 TLS 1.0。
默认情况下，如果未使用 TLS，并且客户端或服务器上未启用此设置，则服务器和客户端之间的远程桌面协议 (RDP) 通道将使用密钥长度为 128 位的 RC4 算法进行加密。在基于 Windows Server 2003 的计算机上启用此设置后，将出现以下情况：RDP 通道将使用密钥长度为 168 位的密码块链接 (CBC) 模式中的 3DES 算法进行加密。SHA-1 算法用于创建消息摘要。客户端必须使用 RDP 5.2 客户端程序或更高版本进行连接。
因此，这两种方法都支持 RDP 只能使用 3DES 的观点。但是，本文建议可以使用更广泛的密码：FIPS 140 验证
远程桌面协议 (RDP) 服务器将使用的加密算法集范围如下： - CALG_RSA_KEYX - RSA 公钥交换算法 - CALG_3DES - 三重 DES 加密算法 - CALG_AES_128 - 128 位 AES - CALG_AES_256 - 256 位 AES - CALG_SHA1 - SHA 哈希算法 - CALG_SHA_256 - 256 位 SHA 哈希算法 - CALG_SHA_384 - 384 位 SHA 哈希算法 - CALG_SHA_512 - 512 位 SHA 哈希算法
最终，尚不清楚在启用 FIPS 模式时 RDP 是否可以支持非 3DES 协议，但有证据表明它不支持。
我没有看到任何证据表明 Server 2012 R2 的功能与 Server 2008 R2 不同，但 Server 2008 R2 似乎基于 FIPS 140-1 合规性，而 Server 2012 R2 遵循 FIPS 140-2，因此 Server 2012 R2 完全有可能支持其他协议。您会注意到FIPS 140 验证关联。
综上所述：我认为 Server 2008 R2 无法在禁用 3DES 的情况下在 FIPS 模式下支持 RDP。我的建议是确定您的系统是否满足 SWEET32 攻击的条件（单个会话中发送的数据超过 768GB），以及禁用 3DES 是否值得删除 RDP 功能。除了 RDP 之外，还有其他实用程序可以管理服务器，尤其是在虚拟化非常普遍的世界中。
答案3
我遇到了同样的问题，在服务器上安装 KB3080079 补丁可支持 tls 1.1 和 1.2。
请注意，对于 Windows 7 客户端，您必须安装 rdp 客户端更新 (KB2830477)，否则只有 Windows 8+ 才能连接。
答案4
显然，2008 和 2012 存在语法问题，并且 2008/7 需要尾随 /168。2012/8.1/10 则不需要。
2008 上的密钥如下所示： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
**很棒的发现，我在一些 Windows 2008 R2 域控制器上遇到了完全相同的问题，奇怪的是我的成员 2008R2 服务器似乎没问题……而且我的 2012R2 服务器也运行良好。需要努力解除那些较旧的 DC 的委托 :)