漏洞扫描经常在 Windows 服务器的 3389 端口（RDP）上报出 CVE-2016-2183，也就是 SSL/TLS 协议信息泄露（SWEET32）。根因是 Windows 默认启用了一组弱密码套件，其中 3DES 使用 64 位分组，长会话流量积累到一定量后就可能被生日攻击还原出敏感内容，扫描器因此报警。

这个问题不用装补丁：在本地组策略里把 SSL 密码套件顺序替换成一份去掉弱项的清单，再重启即可。本文按排错的顺序展开——现象、原因、修复步骤、修复后怎么验证。

原因分析

CVE-2016-2183 针对的是 3DES 这类 64 位分组的块密码。TLS 会话里同一个密钥加密的数据量超过分组空间的一定比例后，攻击者靠碰撞分析就能猜出内容片段，这就是 SWEET32 攻击的名字由来。RDP 会话长时间保持连接、流量持续增长，恰好踩在这个场景上。

Windows 的 TLS 栈由 SChannel 统一提供，默认套件清单里包含 TLS_RSA_WITH_3DES_EDE_CBC_SHA 这类 3DES 条目——扫描器报的正是它。所以修复思路不是打补丁，而是把这份清单换成不含弱项的版本。

操作步骤

1. 打开本地组策略编辑器

win+R 运行，输入 gpedit.msc，进入本地计算机策略。

2. 定位到 SSL 配置设置

本地计算机组策略 → 计算机配置 → 管理模板 → 网络 → SSL 配置设置。

3. 打开 SSL 密码套件顺序

双击打开”SSL 密码套件顺序”，状态改为”已开启”。刚开启时文本框里是系统默认的套件清单，共 35 个，按 Windows 认为安全的顺序排列——末尾一条就是 TLS_RSA_WITH_3DES_EDE_CBC_SHA，扫描器报的弱套件正是它。

配图

4. 替换密码套件内容

在已开启状态下，把密码套件文本框里的内容整体替换为下面这串（共 34 个套件，以逗号分隔）：

1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA

这份清单就是系统默认顺序删掉末尾 TLS_RSA_WITH_3DES_EDE_CBC_SHA 后的版本。这一步是最容易翻车的地方：网上流传的部分”修复清单”照抄了系统默认顺序，35 个套件一个没删，替换完重扫漏洞照样在。粘贴之前先确认整串里没有 3DES 条目，也不要带换行和尾部逗号。

5. 重启计算机

重启后策略生效。生产环境请仔细衡量重启风险，挑维护窗口操作。

验证已修复

重启完成后按两步确认：

  1. 重新打开”SSL 密码套件顺序”策略项，状态应为”已开启”，且文本框内容与粘贴的清单一致；
  2. 重跑一次漏洞扫描，确认 CVE-2016-2183 不再报出。

想不等扫描器、自己先查一遍，有两条路。

第一条从远端查：用 nmap 的 ssl-enum-ciphers 脚本列出 3389 实际协商的套件，输出里不应再有任何带 3DES 的条目：

1
nmap --script ssl-enum-ciphers -p 3389 <服务器IP>

注：此命令未实跑（Windows 组策略环境无法容器化验证），来源为 nmap 官方脚本文档；输出以实际环境为准。

第二条在本机查：Windows Server 2016 及以上的 PowerShell 里可以看 SChannel 实际生效的套件清单，过滤 3DES 后应无输出：

1
Get-TlsCipherSuite | Where-Object { $_.Name -match "3DES" }

注：此命令未实跑，来源为 Microsoft Get-TlsCipherSuite 官方文档；该命令在 Windows Server 2012 R2 及更早系统上不可用。

注意事项

  • 密码套件内容是一整段逗号分隔的字符串，粘贴时不要带换行、不要多出尾部逗号；替换后的正确数量是 34 个，少了或多了都要回头核对。
  • 这条组策略作用于 Windows 的 SChannel，影响的不只是 RDP，IIS 等走系统 TLS 栈的服务同样会改用这份套件清单，改前确认客户端兼容性——极老的客户端若只支持 3DES，会被直接拒绝握手。
  • 域环境下注意本地组策略可能被域策略覆盖：改完发现清单又被还原成默认 35 个，去查同一路径的域 GPO。
  • 如果 3389 前面还有负载均衡或网关在终结 TLS，弱套件要在那一层另行处理，Windows 侧改了也不解决网关的问题。

回到扫描器报告本身：替换套件清单并重启后重扫一次，CVE-2016-2183 报警消失，这条漏洞才算真正闭环。

本文由作者 2020-2024 年间的 CSDN 博客文章重构而来，原发布于 CSDN。