上周帮同事排查一台还在跑老业务系统的 IIS 服务器安全扫描报告拉出来前三条高危清一色指向同一个问题目标站点的 443 端口仍然接受 TLS 1.0 和 TLS 1.1 握手。这件事在纸面上看起来就是个改两个注册表键的小活但真正落到生产环境从现状盘点、配置落地、验证闭环到兼容性兜底中间能踩的坑比想象中多得多。IIS 本身并不实现 TLS它只是把加密握手整个甩给了 Windows 的 Schannel 安全提供程序这意味着你改的不是某个网站的配置而是整台服务器所有走 Schannel 的连接——远程桌面、数据库、目录服务、出站 HTTP 调用全都会跟着一起变。这篇就把这套流程从头到尾拆一遍包括哪些键值是真的有用、哪些网上流传的写法其实是错的、以及改完之后怎么证明它确实生效了。1. 一台还在跑业务的老 IIS为什么突然要动协议的开关TLS 1.0 是 1999 年的产物TLS 1.1 是 2006 年的这两个版本在今天的问题不在于老而在于它们支持的加密套件里混着一批已经被证明不安全的组合比如 CBC 模式下的填充预言攻击面、可被降级的弱密钥交换、以及对 RC4 这类流密码的兼容保留。绝大多数合规扫描器判定TLS 1.0 已启用的逻辑其实非常简单粗暴它用 TLS 1.0 的 ClientHello 发起握手只要服务端返回了 ServerHello 而不是 alert就直接标红。也就是说只要你的服务端还愿意谈哪怕业务上根本没人用这个版本也会被判定为风险暴露面。1.1 扫描报告判的到底是什么很多人第一次看到这个报告会疑惑我的网站明明只在浏览器里被现代客户端访问怎么会用到 TLS 1.0。答案是会不会用和能不能用是两件事。扫描器只关心后者。攻击者构造一个降级握手或者在中间人位置诱导客户端回退到 TLS 1.0只要服务端不拒绝攻击链就成立。所以这条高危的本质是协议协商的下降空间没有被封死而不是当前正在被使用。理解了这一点你就明白为什么加固的目标不是让业务跑在 TLS 1.2 上而是让服务端在任何情况下都不接受低于 TLS 1.2 的协商。这两者的验收标准完全不同前者看一眼浏览器地址栏的锁就够了后者必须做逐版本的握手探测从 TLS 1.0、1.1 一直试到 1.2 和 1.3确认前两个必然失败。还有一个容易被忽略的点扫描器扫的往往是你暴露在公网的那个入口但真实的服务链路可能是公网入口 → 反向代理或负载均衡 → IIS。如果 TLS 是在前面那层终止的那你在 IIS 上做的任何协议配置对扫描结果都毫无影响这一点我在第 2 节会单独展开因为它是最常见的改了半天没效果的根因。1.2 禁用协议改的不是 IIS是整台机器的加密栈这里必须先把一个概念钉死IIS 的 TLS 能力来自 Windows 的 Schannel SSP注册表路径是HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL。所有依赖 Schannel 的组件共享这套配置包括但不限于组件是否受 Schannel 协议开关影响说明IIS 站点HTTPS 绑定是直接走 Schannel远程桌面服务RDP是新版用 TLS 承载老客户端协商能力弱SQL Server 加密连接是老版本实例只支持 TLS 1.0域控的 LDAPS是老客户端可能协商失败WinHTTP 出站请求间接还要叠加 WinHTTP 自己的协议掩码.NET 应用的出站调用间接还要叠加 .NET Framework 的开关计划任务里调用的 curl / 老工具视实现而定自带 TLS 库的不受影响这张表的价值在于它告诉你禁用 TLS 1.0/1.1 是一次整机级的变更而不是网站级的变更。我在第一次做这件事的时候只想着把 HTTPS 站点的扫描项消掉结果改完之后运维同事反馈远程桌面连不上了——因为当时用的那台跳板机上的客户端版本比较老只认 TLS 1.0。这个教训让我后来每次动手前都会先问三个问题这台机器上还跑着什么服务、有没有老版本客户端会连进来、出站方向有没有依赖旧协议的目标。提示如果你只是想让某个 IIS 站点不支持旧协议而机器上其他服务必须保留唯一的办法是把 TLS 终止前移到反向代理层让代理只对外提供 TLS 1.2代理到 IIS 走回环 HTTP。不要试图在单机上做按站点区分协议版本Schannel 没有这个粒度。2. 动手之前先把家底摸清三个维度的现状盘点我见过太多人上来就直接改注册表改完重启然后用浏览器打开首页看到能访问就收工。这种做法的风险在于你根本不知道自己改之前系统是什么状态出了问题也没法判断是新引入的还是本来就有的。所以正式动手之前至少要摸清三件事操作系统版本和补丁级别、Schannel 当前的协议配置快照、以及 TLS 到底在哪一层终止。2.1 操作系统版本决定了这条路能走多远TLS 1.2 的支持情况在不同 Windows Server 版本上差异很大这个差异直接决定了你的加固方案能不能落地。粗略的对应关系是这样的系统版本TLS 1.2 支持情况需要额外做的事Server 2008 SP2需补丁支持必须先装补丁否则键值改了也没用Server 2008 R2 SP1原生支持但默认不作为首选需要装补丁让 .NET 和 WinHTTP 认识 TLS 1.2Server 2012 / 2012 R2原生支持默认启用只需改 Schannel 与应用层开关Server 2016 及以上原生支持密码套件策略位置有变化密码套件顺序改到策略键下Server 2022支持 TLS 1.3需显式启用可以顺手把 1.3 打开如果盘点下来发现是 2008 R2那你就要做好心理准备这台机器上跑的老应用很可能用的是 .NET Framework 4.0 甚至 2.0 的应用程序池而这些运行时默认的协商版本里根本没有 TLS 1.2。光改 Schannel 是不够的还得把应用层的开关一起拨过去否则会出现外部客户端连进来是 TLS 1.2但应用自己往外调接口还是 TLS 1.0的诡异局面。快速确认版本和补丁情况我一般用这两条# 看系统版本与构建号 Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, WindowsVersion # 看关键补丁是否在位以 2008 R2 的 TLS 1.2 支持补丁为例 Get-HotFix | Where-Object { $_.HotFixID -like KB* } | Sort-Object InstalledOn -Descending | Select-Object -First 20第二条命令列出来的东西要肉眼看一遍重点是确认那几个和 TLS 相关的累积更新在不在。补丁不在位的情况下改注册表属于白改。2.2 把当前的 Schannel 配置导出一份快照改之前先备份这是常识但很多人只备份了要改的那两个键忽略了整棵Protocols子树可能还有其他非默认配置。我习惯直接导整棵子树$stamp Get-Date -Format yyyyMMdd_HHmmss $backup C:\Backup\Schannel_$stamp.reg reg export HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL $backup /y Write-Host 已导出到 $backup导完之后先别急着改把现有内容读出来看一眼重点确认三件事TLS 1.0 和 1.1 的Server子键是否存在很多系统上压根没有这个键需要手动创建、Enabled的值当前是 0 还是 1、以及有没有人之前加过DisabledByDefault但没设Enabled。Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols -Recurse | ForEach-Object { $props Get-ItemProperty $_.PSPath [PSCustomObject]{ Path $_.PSPath -replace .*Protocols\\, Enabled $props.Enabled DisabledByDefault $props.DisabledByDefault } } | Format-Table -AutoSize这条命令跑出来的表格就是你这台机器的协议现状地图。如果Enabled那一列大量显示为空说明系统在吃默认值这种情况下你设Enabled0是有效的新增配置如果显示为 1说明有人显式开过你需要确认这是业务需要还是历史遗留。2.3 先搞清楚 TLS 到底在哪一层终止这一步是我认为最容易被跳过、但价值最高的一步。判断方法很直接在服务器本机执行一次针对自己 443 端口的握手测试再从一个外部网络位置对公网域名做一次同样的测试对比结果。如果本机测试显示支持 TLS 1.0但外部测试显示不支持说明前面有设备在做 TLS 终止或者协议过滤你改 IIS 所在的这台机器没用得去改那台设备。反过来如果两边一致说明确实是这台机器在直接对外提供 TLS配置改在这里才有意义。还有一种更隐蔽的情况前面是四层负载均衡只做 TCP 转发不做 TLS 终止那 TLS 确实是在 IIS 上终止的改注册表有效但健康检查探针可能是用 TLS 1.0 发起的改完之后探针失败负载均衡把节点摘了业务全挂。这个坑我在第 6 节会详细讲怎么提前发现。3. Schannel 注册表的两组开关Server 键与 Client 键现在进入正题。TLS 1.0 和 1.1 在注册表里的位置是固定的区别只在于Protocols下面按协议名建子键每个协议名下面再分Server和Client两个角色键。Server管的是别人连我Client管的是我去连别人。很多人只知道改Server结果业务里调用外部接口的那部分开始报错回头一查才发现是Client没处理。3.1 Enabled 与 DisabledByDefault 的真实语义这两个 DWORD 值的含义经常被混淆我见过不少文档把它们写成设一个就行这是不准确的。准确的说法是键值含义推荐设置Enabled0 该协议在该角色下完全不可用1 可用禁用时设 0DisabledByDefault0 默认参与协商1 默认不参与但可以被显式请求禁用时设 1只设Enabled0的效果是彻底关闭握手阶段直接不认这个版本只设DisabledByDefault1的效果是默认不用但客户端明确要求时还能谈。从加固的角度两个都设才是干净的做法因为扫描器有些会做显式请求 TLS 1.0的探测只设后者会被判定为仍然支持。还有一个细节Client键下的Enabled0影响的是本机作为客户端发起连接时的行为。如果这台服务器上有应用需要去连一个只支持 TLS 1.0 的老系统比如某台老打印机、老监控设备的管理接口、或者某个没升级过的第三方服务那Client键一关这个连接立刻断。所以我的做法是Server键果断关Client键先盘点出站依赖再决定。3.2 一段可以反复执行的 PowerShell 落地脚本手工点注册表编辑器容易出错尤其是键不存在的时候还要手动建。我写了一段幂等的脚本跑几次结果都一样也不怕中间失败重跑$protocols (TLS 1.0, TLS 1.1) $roles (Server, Client) $base HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols foreach ($proto in $protocols) { foreach ($role in $roles) { $path Join-Path $base $proto\$role if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null Write-Host 创建键: $path } New-ItemProperty -Path $path -Name Enabled -Value 0 -PropertyType DWord -Force | Out-Null New-ItemProperty -Path $path -Name DisabledByDefault -Value 1 -PropertyType DWord -Force | Out-Null Write-Host 已配置: $path } } Write-Host Schannel 协议开关配置完成需重启相关服务或主机后生效。这里有个实操上的细节值得说New-ItemProperty -Force在键已存在但值不存在时会创建值已存在时会覆盖所以是幂等的。但New-Item -Force在路径中间层不存在时会一路创建上去这一点恰好符合我们的需要因为很多系统上TLS 1.1这个键压根不存在。改完之后生效方式有两种选择一是重启整机最彻底二是重启W3SVC服务让w3wp进程重新加载 Schannel 配置。我的经验是如果这台机器上只跑 IISiisreset /restart基本够用如果还跑着 RDP、SQL Server 之类的那些服务进程不会因为iisreset而重启它们的连接行为要等到下一次进程重启才变化所以这种情况下乖乖挑个维护窗口重启整机更稳妥。3.3 顺手把 SSL 3.0、RC4 和 3DES 一起收拾掉既然已经动到这一层了只关 TLS 1.0/1.1 而留着 SSL 3.0 是很奇怪的后者的问题比前者严重得多。同理RC4 和 3DES 这两种分组加密也不该继续留在可用套件列表里。它们的配置路径和协议开关不同; SSL 3.0 完全禁用 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] Enableddword:00000000 DisabledByDefaultdword:00000001 ; RC4 系列禁用 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] Enableddword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128] Enableddword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] Enableddword:00000000 ; 3DES 禁用 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168] Enableddword:00000000注意Ciphers下面这些子键的命名带斜杠比如RC4 128/128在.reg文件里可以直接写但在 PowerShell 里拼接路径时要小心斜杠被误解析我一般用-LiteralPath参数来规避。这里有一个我踩过的坑禁掉 3DES 之后某些老版本的 Java 客户端连不上来了。原因是那些客户端的可用套件列表里恰好只剩 AES-CBC 加 3DES而 AES-GCM 因为版本太老不被支持。解决办法不是把 3DES 加回来而是推动客户端升级——但如果短期推不动就得在合规和可用之间做取舍这个决策必须提前跟业务方对齐而不是等技术上改完了再被动回滚。4. 协议关了不等于应用会走新协议.NET 与 WinHTTP 的独立开关这一节是我认为最容易被低估的部分。Schannel 的开关控制的是这个协议能不能用但应用程序用什么协议发起连接是由各自的运行时决定的。一个用 .NET Framework 4.0 编译的老程序即便系统完整支持 TLS 1.2它默认的ServicePointManager.SecurityProtocol里也可能只有 SSL3 和 TLS 1.0。你把 TLS 1.0 在系统层禁掉这个程序的表现不是自动升级到 TLS 1.2而是直接连不上。4.1 SchUseStrongCrypto 与 SystemDefaultTlsVersions 的分工这两个键经常被混为一谈实际上它们解决的问题不一样键名位置作用建议值SchUseStrongCrypto.NETFramework\v4.0.30319及 Wow6432Node让 .NET 优先使用强加密算法影响的是加密套件偏好1SystemDefaultTlsVersions同上让 .NET 跟随系统 Schannel 的协议配置而不是自己硬编码一份1SystemDefaultTlsVersions是更关键的那个。设成 1 之后.NET 应用不再自己决定用哪个 TLS 版本而是完全听系统的——这正好和我们在第 3 节做的 Schannel 配置形成闭环系统支持什么应用就用什么系统禁了什么应用也就用不了什么。设成 0 或者不设应用就会用运行时内置的默认值在老版本上这个默认值往往是 SSL3 加 TLS 1.0。配置的方式如下注意 64 位系统上要同时写Wow6432Node分支否则 32 位应用池里跑的程序不受影响$paths ( HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319, HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 ) foreach ($p in $paths) { if (Test-Path $p) { New-ItemProperty -Path $p -Name SystemDefaultTlsVersions -Value 1 -PropertyType DWord -Force | Out-Null New-ItemProperty -Path $p -Name SchUseStrongCrypto -Value 1 -PropertyType DWord -Force | Out-Null Write-Host 已写入: $p } }如果这台机器上还跑着 2.0 的应用程序池v2.0.50727情况会更麻烦一些那个运行时对 TLS 1.2 的支持需要额外的补丁而且开关位置也不同。遇到这种情况我通常建议先确认这个应用池到底还在不在用很多所谓的遗留应用其实早就没人访问了只是没人敢删而已。4.2 出站请求走 WinHTTP 时的位掩码怎么算如果这台 IIS 上的应用是用HttpClient、WebRequest或者某些第三方组件发 HTTP 请求出去的那还要考虑 WinHTTP 这一层。WinHTTP 有自己的协议选择掩码位置在[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] DefaultSecureProtocolsdword:00000A00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] DefaultSecureProtocolsdword:00000A00这个 DWORD 是位掩码每个协议占一位协议十六进制值十进制SSL 2.00x0000002032SSL 3.00x0000004064TLS 1.00x00000080128TLS 1.10x00000200512TLS 1.20x000008002048如果需要只用 TLS 1.2那就是0x00000800如果TLS 1.1 和 1.2 都行就是0x00000A00。我一般填0x00000A00而不是只留 1.2理由是有些老一点的目标服务只支持到 1.1一刀切到 1.2 容易在出站方向制造莫名其妙的失败而 TLS 1.1 本身在出站场景的风险远小于入站服务端不会主动降级出站是你主动选择连谁。当然如果合规要求严格直接上0x00000800也没问题。4.3 代码里写死 SecurityProtocol 的老项目怎么办有一种情况是任何注册表都救不了的代码里显式设置了协议版本。比如ServicePointManager.SecurityProtocol SecurityProtocolType.Tls;这一行写下去无论系统怎么配这个进程发出的请求都只用 TLS 1.0。系统层禁掉之后这个连接就会直接抛异常报错信息通常是基础连接已关闭或者无法建立 SSL/TLS 的安全通道。排查这种问题的思路是先在服务器上用抓包或者握手日志确认出站连接实际协商的协议版本如果发现用的还是 TLS 1.0那就说明是应用层写死的。这种情况下没有配置层的解法只能改代码改成SecurityProtocolType.SystemDefault或者至少加上Tls12。对于短期改不了代码的还有一个折中方案在系统层用兼容性开关做例外。但这属于技术债挂账不是长久之计而且每加一个例外就多一个需要记录和跟踪的隐患。5. 验证闭环从本机回环到外部扫描的三层确认改完配置重启服务浏览器能打开页面这只能证明 TLS 1.2 通了不能证明 TLS 1.0 被拒了。真正的验收必须做逐版本的否定测试——每个版本都要单独确认它失败了而不是笼统地确认某个版本成功了。5.1 本机逐版本握手测试的正确姿势我用得最多的是openssl s_client因为它可以精确指定协议版本而且输出信息足够详细# 测试 TLS 1.0期望失败 openssl s_client -connect 127.0.0.1:443 -tls1 -servername your.domain.local # 测试 TLS 1.1期望失败 openssl s_client -connect 127.0.0.1:443 -tls1_1 -servername your.domain.local # 测试 TLS 1.2期望成功 openssl s_client -connect 127.0.0.1:443 -tls1_2 -servername your.domain.local失败的输出通常会是alert handshake failure、no protocols available或者wrong version number成功的话会看到Verify return code和协商出来的协议版本。这里有个细节要注意加-servername参数是必须的因为 IIS 上是靠 SNI 来区分站点的不传这个参数可能会连到默认站点测出来的结果就不是你想要的那一个。Windows 环境下如果没装 openssl也可以用 PowerShell 的Tls12参数做简化测试# PowerShell 5.1 默认用 TLS 1.0/1.1能连上就说明旧协议还开着 try { Invoke-WebRequest -Uri https://127.0.0.1 -UseBasicParsing -TimeoutSec 10 | Out-Null Write-Host 旧协议仍可用 -ForegroundColor Red } catch { Write-Host 旧协议已被拒绝: $($_.Exception.Message) -ForegroundColor Green }这条命令的逻辑比较取巧PowerShell 5.1 的默认协议栈里包含 TLS 1.0所以在协议被禁掉之后它应该连接失败。如果它成功了说明关闭没有生效或者这台机器的 PowerShell 版本比较新7.x 默认走系统配置那就需要用-SslProtocol参数显式指定。5.2 外部视角的确认与两个常见误判本机测试通过之后从外部网络位置再做一次同样的测试这一步不能省。我遇到过两次本机测试通过、外部测试失败的情况原因一次是负载均衡设备对特定版本做了过滤另一次是中间的 WAF 拦了 TLS 1.0 握手并返回了自己的 alert导致从外部看起来像是服务端不支持实际上服务端的问题根本没解决。外部测试的工具选择上nmap的ssl-enum-ciphers脚本输出最直观nmap --script ssl-enum-ciphers -p 443 your.domain.com它会按协议版本分组列出每个版本支持的密码套件禁用的版本会明确标注。另一种误判是浏览器能打开就以为没问题。现代浏览器早就放弃了对 TLS 1.0 的支持它压根不会去尝试这个版本所以你用浏览器访问成功只能证明 TLS 1.2/1.3 正常对 1.0 是否被禁用没有任何信息量。这个逻辑关系一定要理清楚否则验收就是自欺欺人。5.3 怎么确认没有老客户端被挡在门外验证的另一面是确认该通的还通着。这部分不能靠主动探测只能靠日志。IIS 的 HTTPERR 日志和 Windows 系统日志里的 Schannel 事件是两个主要来源。Schannel 的握手失败事件在系统日志里事件源是Schannel事件 ID 通常是 36871创建安全通道时发生致命错误或者 36888。打开事件查看器按源过滤能看到失败的时间点和错误码。如果加固上线后这类事件量突然暴涨说明有大量客户端在用旧协议连接需要立刻评估是不是回滚。Get-WinEvent -FilterHashtable { LogName System ProviderName Schannel StartTime (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, Message | Format-List我的习惯是在上线后盯至少 24 小时的这个事件流尤其是业务高峰时段。有些老客户端不是全天在线比如某些定时任务、某些只在夜间跑的数据同步白天看着没事晚上才炸这是很典型的翻车模式。6. 上线之后最容易翻车的几类连接前面讲的都是怎么改和怎么验但这套改动真正的风险不在配置本身而在于它影响范围太广。这一节把我实际遇到过的事故按类型归一下方便你在动手前做一次针对性的自查。6.1 远程桌面、数据库、目录服务的连带影响这三个是我见过的最高频的连带故障源。远程桌面的情况比较微妙新版 Windows 的 RDP 客户端支持 TLS 1.2老版本尤其是某些精简版系统、某些第三方 RDP 客户端、移动端的老版本 App只支持 TLS 1.0。一旦服务端的 TLS 1.0 被禁这些客户端连上来会直接提示由于发生身份验证错误要求的函数不受支持或者干脆卡在连接中。所以动手前一定要确认所有需要远程管理这台机器的人用的是不是新版客户端。数据库连接的情况取决于实例版本。老版本的数据库实例在启用加密连接时协商能力可能只到 TLS 1.0这时候如果客户端强制走 TLS 1.2或者服务端禁了 1.0连接直接失败。这类问题往往不会在应用启动时就暴露而是等到某个走加密连接的模块被调用时才炸排查起来很费时间。目录服务的 LDAPS 是另一回事。如果这台 IIS 所在的机器需要向目录服务做加密查询而目录服务端还是老系统禁掉本机Client键的 TLS 1.0 之后这个查询会失败。表现是某些依赖身份认证的功能时好时坏日志里能看到 LDAP 相关的异常。注意这三类问题有一个共同特征——它们都不走 IIS 的 443 端口所以你在验证 HTTPS 站点的时候完全发现不了。做现状盘点时务必把这台机器上还有什么服务在监听端口作为必查项。6.2 出站调用报基础连接已关闭的排查链路这个报错是 .NET 出站请求失败时最常见的措辞但它背后的原因至少有四种必须按顺序排除第一步确认是协议协商失败还是证书校验失败。看异常的InnerException如果是AuthenticationException且消息里带SSL/TLS字样基本可以锁定协议问题如果是TrustFailure那是证书链的问题跟本次改动无关。第二步确认应用层有没有写死协议版本。在代码里搜SecurityProtocol或者用strings之类的工具在编译产物里找。这一步能排掉很大一部分改了配置没用的困惑。第三步确认系统的SystemDefaultTlsVersions和SchUseStrongCrypto是否两个分支都写了。只写 64 位分支而应用池是 32 位的这个组合我见过不止一次。第四步确认目标服务端到底支持什么版本。有时候问题不在你这边而是对方只支持 TLS 1.0你禁了之后自然连不上。这种情况下要么推动对方升级要么在出站方向上单独放行——但请注意Schannel 的协议开关是全局的没有只对某个目标放行的粒度真要这么做得靠应用层自己处理。6.3 回滚脚本与灰度分批的实操节奏回滚这事儿我坚持一个原则回滚脚本必须在改动之前就写好并测试过而不是出事之后现场手写。原因很简单出事的时候人都是慌的手写容易出错而且容易漏掉某个键。回滚的逻辑就是把前面所有设置反向操作一遍$protocols (TLS 1.0, TLS 1.1) $roles (Server, Client) $base HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols foreach ($proto in $protocols) { foreach ($role in $roles) { $path Join-Path $base $proto\$role if (Test-Path $path) { Set-ItemProperty -Path $path -Name Enabled -Value 1 -Type DWord Set-ItemProperty -Path $path -Name DisabledByDefault -Value 0 -Type DWord } } } Write-Host 已回滚协议开关请重启相关服务。灰度方面如果有多台服务器做负载均衡绝对不要一次全改。我的节奏是先改一台观察 24 到 48 小时重点看 Schannel 失败事件的数量和业务侧的错误率确认无异常后再改第二批比如 30%再观察最后全量。单机环境下没有灰度空间那就把观察期拉长并且提前和业务方约好可回滚的时间窗口。还有一点回滚不等于万事大吉。如果你已经改了两天期间有客户端尝试连接失败并被记录为业务异常那这些影响是既成事实。所以加固这件事最好挑业务低峰期做而且提前发个通知让依赖这台服务器的人有个心理准备。7. 几次加固下来我改掉的几个习惯最开始做这类加固我的习惯是看文档、改键值、重启、收工后来吃过几次亏现在流程完全反过来了。第一个改掉的习惯是不再相信改完重启就行。现在我一定会做逐版本的否定测试而且是从外部做的。因为本机测试有太多方式可以骗过你——回环地址走的路径、SNI 的默认站点、本机 hosts 文件的解析结果任何一个环节出问题测出来的都不是真实结果。第二个改掉的习惯是不再只备份要改的键。现在我导整棵SCHANNEL子树原因是有一次发现某个键被之前的人改过但改成了一个很奇怪的值如果不导全量根本看不出来。备份的意义不只是能恢复更是能对比。第三个改掉的习惯是不再把浏览器能打开当成验收通过。这个习惯最难改因为它太符合直觉了。但前面分析过现代浏览器根本不会去试 TLS 1.0浏览器能打开和旧协议被禁用之间没有因果关系。最后一个我现在会强制自己在动手前列一份这台机器上还有谁在用 TLS的清单。清单不长但每次列的时候都能发现一两个之前没想到的某个只在月底跑一次的报表同步任务、某个用来做监控告警的脚本、某个运维同事私自在上面装的小工具。这些东西不会主动告诉你它们依赖旧协议只会在你改完之后安静地坏掉。如果要说这套流程里最值得投入时间的一步我会选现状盘点。改配置本身十分钟就能搞定真正决定成败的是改之前你有没有搞清楚这台机器上到底跑着什么、连着谁、被谁连着。盘得清楚后面全是顺水推舟盘不清楚后面全是救火。
上周帮同事排查一台还在跑老业务系统的 IIS 服务器安全扫描报告拉出来前三条高危清一色指向同一个问题目标站点的 443 端口仍然接受 TLS 1.0 和 TLS 1.1 握手。这件事在纸面上看起来就是个改两个注册表键的小活但真正落到生产环境从现状盘点、配置落地、验证闭环到兼容性兜底中间能踩的坑比想象中多得多。IIS 本身并不实现 TLS它只是把加密握手整个甩给了 Windows 的 Schannel 安全提供程序这意味着你改的不是某个网站的配置而是整台服务器所有走 Schannel 的连接——远程桌面、数据库、目录服务、出站 HTTP 调用全都会跟着一起变。这篇就把这套流程从头到尾拆一遍包括哪些键值是真的有用、哪些网上流传的写法其实是错的、以及改完之后怎么证明它确实生效了。1. 一台还在跑业务的老 IIS为什么突然要动协议的开关TLS 1.0 是 1999 年的产物TLS 1.1 是 2006 年的这两个版本在今天的问题不在于老而在于它们支持的加密套件里混着一批已经被证明不安全的组合比如 CBC 模式下的填充预言攻击面、可被降级的弱密钥交换、以及对 RC4 这类流密码的兼容保留。绝大多数合规扫描器判定TLS 1.0 已启用的逻辑其实非常简单粗暴它用 TLS 1.0 的 ClientHello 发起握手只要服务端返回了 ServerHello 而不是 alert就直接标红。也就是说只要你的服务端还愿意谈哪怕业务上根本没人用这个版本也会被判定为风险暴露面。1.1 扫描报告判的到底是什么很多人第一次看到这个报告会疑惑我的网站明明只在浏览器里被现代客户端访问怎么会用到 TLS 1.0。答案是会不会用和能不能用是两件事。扫描器只关心后者。攻击者构造一个降级握手或者在中间人位置诱导客户端回退到 TLS 1.0只要服务端不拒绝攻击链就成立。所以这条高危的本质是协议协商的下降空间没有被封死而不是当前正在被使用。理解了这一点你就明白为什么加固的目标不是让业务跑在 TLS 1.2 上而是让服务端在任何情况下都不接受低于 TLS 1.2 的协商。这两者的验收标准完全不同前者看一眼浏览器地址栏的锁就够了后者必须做逐版本的握手探测从 TLS 1.0、1.1 一直试到 1.2 和 1.3确认前两个必然失败。还有一个容易被忽略的点扫描器扫的往往是你暴露在公网的那个入口但真实的服务链路可能是公网入口 → 反向代理或负载均衡 → IIS。如果 TLS 是在前面那层终止的那你在 IIS 上做的任何协议配置对扫描结果都毫无影响这一点我在第 2 节会单独展开因为它是最常见的改了半天没效果的根因。1.2 禁用协议改的不是 IIS是整台机器的加密栈这里必须先把一个概念钉死IIS 的 TLS 能力来自 Windows 的 Schannel SSP注册表路径是HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL。所有依赖 Schannel 的组件共享这套配置包括但不限于组件是否受 Schannel 协议开关影响说明IIS 站点HTTPS 绑定是直接走 Schannel远程桌面服务RDP是新版用 TLS 承载老客户端协商能力弱SQL Server 加密连接是老版本实例只支持 TLS 1.0域控的 LDAPS是老客户端可能协商失败WinHTTP 出站请求间接还要叠加 WinHTTP 自己的协议掩码.NET 应用的出站调用间接还要叠加 .NET Framework 的开关计划任务里调用的 curl / 老工具视实现而定自带 TLS 库的不受影响这张表的价值在于它告诉你禁用 TLS 1.0/1.1 是一次整机级的变更而不是网站级的变更。我在第一次做这件事的时候只想着把 HTTPS 站点的扫描项消掉结果改完之后运维同事反馈远程桌面连不上了——因为当时用的那台跳板机上的客户端版本比较老只认 TLS 1.0。这个教训让我后来每次动手前都会先问三个问题这台机器上还跑着什么服务、有没有老版本客户端会连进来、出站方向有没有依赖旧协议的目标。提示如果你只是想让某个 IIS 站点不支持旧协议而机器上其他服务必须保留唯一的办法是把 TLS 终止前移到反向代理层让代理只对外提供 TLS 1.2代理到 IIS 走回环 HTTP。不要试图在单机上做按站点区分协议版本Schannel 没有这个粒度。2. 动手之前先把家底摸清三个维度的现状盘点我见过太多人上来就直接改注册表改完重启然后用浏览器打开首页看到能访问就收工。这种做法的风险在于你根本不知道自己改之前系统是什么状态出了问题也没法判断是新引入的还是本来就有的。所以正式动手之前至少要摸清三件事操作系统版本和补丁级别、Schannel 当前的协议配置快照、以及 TLS 到底在哪一层终止。2.1 操作系统版本决定了这条路能走多远TLS 1.2 的支持情况在不同 Windows Server 版本上差异很大这个差异直接决定了你的加固方案能不能落地。粗略的对应关系是这样的系统版本TLS 1.2 支持情况需要额外做的事Server 2008 SP2需补丁支持必须先装补丁否则键值改了也没用Server 2008 R2 SP1原生支持但默认不作为首选需要装补丁让 .NET 和 WinHTTP 认识 TLS 1.2Server 2012 / 2012 R2原生支持默认启用只需改 Schannel 与应用层开关Server 2016 及以上原生支持密码套件策略位置有变化密码套件顺序改到策略键下Server 2022支持 TLS 1.3需显式启用可以顺手把 1.3 打开如果盘点下来发现是 2008 R2那你就要做好心理准备这台机器上跑的老应用很可能用的是 .NET Framework 4.0 甚至 2.0 的应用程序池而这些运行时默认的协商版本里根本没有 TLS 1.2。光改 Schannel 是不够的还得把应用层的开关一起拨过去否则会出现外部客户端连进来是 TLS 1.2但应用自己往外调接口还是 TLS 1.0的诡异局面。快速确认版本和补丁情况我一般用这两条# 看系统版本与构建号 Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, WindowsVersion # 看关键补丁是否在位以 2008 R2 的 TLS 1.2 支持补丁为例 Get-HotFix | Where-Object { $_.HotFixID -like KB* } | Sort-Object InstalledOn -Descending | Select-Object -First 20第二条命令列出来的东西要肉眼看一遍重点是确认那几个和 TLS 相关的累积更新在不在。补丁不在位的情况下改注册表属于白改。2.2 把当前的 Schannel 配置导出一份快照改之前先备份这是常识但很多人只备份了要改的那两个键忽略了整棵Protocols子树可能还有其他非默认配置。我习惯直接导整棵子树$stamp Get-Date -Format yyyyMMdd_HHmmss $backup C:\Backup\Schannel_$stamp.reg reg export HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL $backup /y Write-Host 已导出到 $backup导完之后先别急着改把现有内容读出来看一眼重点确认三件事TLS 1.0 和 1.1 的Server子键是否存在很多系统上压根没有这个键需要手动创建、Enabled的值当前是 0 还是 1、以及有没有人之前加过DisabledByDefault但没设Enabled。Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols -Recurse | ForEach-Object { $props Get-ItemProperty $_.PSPath [PSCustomObject]{ Path $_.PSPath -replace .*Protocols\\, Enabled $props.Enabled DisabledByDefault $props.DisabledByDefault } } | Format-Table -AutoSize这条命令跑出来的表格就是你这台机器的协议现状地图。如果Enabled那一列大量显示为空说明系统在吃默认值这种情况下你设Enabled0是有效的新增配置如果显示为 1说明有人显式开过你需要确认这是业务需要还是历史遗留。2.3 先搞清楚 TLS 到底在哪一层终止这一步是我认为最容易被跳过、但价值最高的一步。判断方法很直接在服务器本机执行一次针对自己 443 端口的握手测试再从一个外部网络位置对公网域名做一次同样的测试对比结果。如果本机测试显示支持 TLS 1.0但外部测试显示不支持说明前面有设备在做 TLS 终止或者协议过滤你改 IIS 所在的这台机器没用得去改那台设备。反过来如果两边一致说明确实是这台机器在直接对外提供 TLS配置改在这里才有意义。还有一种更隐蔽的情况前面是四层负载均衡只做 TCP 转发不做 TLS 终止那 TLS 确实是在 IIS 上终止的改注册表有效但健康检查探针可能是用 TLS 1.0 发起的改完之后探针失败负载均衡把节点摘了业务全挂。这个坑我在第 6 节会详细讲怎么提前发现。3. Schannel 注册表的两组开关Server 键与 Client 键现在进入正题。TLS 1.0 和 1.1 在注册表里的位置是固定的区别只在于Protocols下面按协议名建子键每个协议名下面再分Server和Client两个角色键。Server管的是别人连我Client管的是我去连别人。很多人只知道改Server结果业务里调用外部接口的那部分开始报错回头一查才发现是Client没处理。3.1 Enabled 与 DisabledByDefault 的真实语义这两个 DWORD 值的含义经常被混淆我见过不少文档把它们写成设一个就行这是不准确的。准确的说法是键值含义推荐设置Enabled0 该协议在该角色下完全不可用1 可用禁用时设 0DisabledByDefault0 默认参与协商1 默认不参与但可以被显式请求禁用时设 1只设Enabled0的效果是彻底关闭握手阶段直接不认这个版本只设DisabledByDefault1的效果是默认不用但客户端明确要求时还能谈。从加固的角度两个都设才是干净的做法因为扫描器有些会做显式请求 TLS 1.0的探测只设后者会被判定为仍然支持。还有一个细节Client键下的Enabled0影响的是本机作为客户端发起连接时的行为。如果这台服务器上有应用需要去连一个只支持 TLS 1.0 的老系统比如某台老打印机、老监控设备的管理接口、或者某个没升级过的第三方服务那Client键一关这个连接立刻断。所以我的做法是Server键果断关Client键先盘点出站依赖再决定。3.2 一段可以反复执行的 PowerShell 落地脚本手工点注册表编辑器容易出错尤其是键不存在的时候还要手动建。我写了一段幂等的脚本跑几次结果都一样也不怕中间失败重跑$protocols (TLS 1.0, TLS 1.1) $roles (Server, Client) $base HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols foreach ($proto in $protocols) { foreach ($role in $roles) { $path Join-Path $base $proto\$role if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null Write-Host 创建键: $path } New-ItemProperty -Path $path -Name Enabled -Value 0 -PropertyType DWord -Force | Out-Null New-ItemProperty -Path $path -Name DisabledByDefault -Value 1 -PropertyType DWord -Force | Out-Null Write-Host 已配置: $path } } Write-Host Schannel 协议开关配置完成需重启相关服务或主机后生效。这里有个实操上的细节值得说New-ItemProperty -Force在键已存在但值不存在时会创建值已存在时会覆盖所以是幂等的。但New-Item -Force在路径中间层不存在时会一路创建上去这一点恰好符合我们的需要因为很多系统上TLS 1.1这个键压根不存在。改完之后生效方式有两种选择一是重启整机最彻底二是重启W3SVC服务让w3wp进程重新加载 Schannel 配置。我的经验是如果这台机器上只跑 IISiisreset /restart基本够用如果还跑着 RDP、SQL Server 之类的那些服务进程不会因为iisreset而重启它们的连接行为要等到下一次进程重启才变化所以这种情况下乖乖挑个维护窗口重启整机更稳妥。3.3 顺手把 SSL 3.0、RC4 和 3DES 一起收拾掉既然已经动到这一层了只关 TLS 1.0/1.1 而留着 SSL 3.0 是很奇怪的后者的问题比前者严重得多。同理RC4 和 3DES 这两种分组加密也不该继续留在可用套件列表里。它们的配置路径和协议开关不同; SSL 3.0 完全禁用 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] Enableddword:00000000 DisabledByDefaultdword:00000001 ; RC4 系列禁用 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] Enableddword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128] Enableddword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] Enableddword:00000000 ; 3DES 禁用 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168] Enableddword:00000000注意Ciphers下面这些子键的命名带斜杠比如RC4 128/128在.reg文件里可以直接写但在 PowerShell 里拼接路径时要小心斜杠被误解析我一般用-LiteralPath参数来规避。这里有一个我踩过的坑禁掉 3DES 之后某些老版本的 Java 客户端连不上来了。原因是那些客户端的可用套件列表里恰好只剩 AES-CBC 加 3DES而 AES-GCM 因为版本太老不被支持。解决办法不是把 3DES 加回来而是推动客户端升级——但如果短期推不动就得在合规和可用之间做取舍这个决策必须提前跟业务方对齐而不是等技术上改完了再被动回滚。4. 协议关了不等于应用会走新协议.NET 与 WinHTTP 的独立开关这一节是我认为最容易被低估的部分。Schannel 的开关控制的是这个协议能不能用但应用程序用什么协议发起连接是由各自的运行时决定的。一个用 .NET Framework 4.0 编译的老程序即便系统完整支持 TLS 1.2它默认的ServicePointManager.SecurityProtocol里也可能只有 SSL3 和 TLS 1.0。你把 TLS 1.0 在系统层禁掉这个程序的表现不是自动升级到 TLS 1.2而是直接连不上。4.1 SchUseStrongCrypto 与 SystemDefaultTlsVersions 的分工这两个键经常被混为一谈实际上它们解决的问题不一样键名位置作用建议值SchUseStrongCrypto.NETFramework\v4.0.30319及 Wow6432Node让 .NET 优先使用强加密算法影响的是加密套件偏好1SystemDefaultTlsVersions同上让 .NET 跟随系统 Schannel 的协议配置而不是自己硬编码一份1SystemDefaultTlsVersions是更关键的那个。设成 1 之后.NET 应用不再自己决定用哪个 TLS 版本而是完全听系统的——这正好和我们在第 3 节做的 Schannel 配置形成闭环系统支持什么应用就用什么系统禁了什么应用也就用不了什么。设成 0 或者不设应用就会用运行时内置的默认值在老版本上这个默认值往往是 SSL3 加 TLS 1.0。配置的方式如下注意 64 位系统上要同时写Wow6432Node分支否则 32 位应用池里跑的程序不受影响$paths ( HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319, HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 ) foreach ($p in $paths) { if (Test-Path $p) { New-ItemProperty -Path $p -Name SystemDefaultTlsVersions -Value 1 -PropertyType DWord -Force | Out-Null New-ItemProperty -Path $p -Name SchUseStrongCrypto -Value 1 -PropertyType DWord -Force | Out-Null Write-Host 已写入: $p } }如果这台机器上还跑着 2.0 的应用程序池v2.0.50727情况会更麻烦一些那个运行时对 TLS 1.2 的支持需要额外的补丁而且开关位置也不同。遇到这种情况我通常建议先确认这个应用池到底还在不在用很多所谓的遗留应用其实早就没人访问了只是没人敢删而已。4.2 出站请求走 WinHTTP 时的位掩码怎么算如果这台 IIS 上的应用是用HttpClient、WebRequest或者某些第三方组件发 HTTP 请求出去的那还要考虑 WinHTTP 这一层。WinHTTP 有自己的协议选择掩码位置在[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] DefaultSecureProtocolsdword:00000A00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] DefaultSecureProtocolsdword:00000A00这个 DWORD 是位掩码每个协议占一位协议十六进制值十进制SSL 2.00x0000002032SSL 3.00x0000004064TLS 1.00x00000080128TLS 1.10x00000200512TLS 1.20x000008002048如果需要只用 TLS 1.2那就是0x00000800如果TLS 1.1 和 1.2 都行就是0x00000A00。我一般填0x00000A00而不是只留 1.2理由是有些老一点的目标服务只支持到 1.1一刀切到 1.2 容易在出站方向制造莫名其妙的失败而 TLS 1.1 本身在出站场景的风险远小于入站服务端不会主动降级出站是你主动选择连谁。当然如果合规要求严格直接上0x00000800也没问题。4.3 代码里写死 SecurityProtocol 的老项目怎么办有一种情况是任何注册表都救不了的代码里显式设置了协议版本。比如ServicePointManager.SecurityProtocol SecurityProtocolType.Tls;这一行写下去无论系统怎么配这个进程发出的请求都只用 TLS 1.0。系统层禁掉之后这个连接就会直接抛异常报错信息通常是基础连接已关闭或者无法建立 SSL/TLS 的安全通道。排查这种问题的思路是先在服务器上用抓包或者握手日志确认出站连接实际协商的协议版本如果发现用的还是 TLS 1.0那就说明是应用层写死的。这种情况下没有配置层的解法只能改代码改成SecurityProtocolType.SystemDefault或者至少加上Tls12。对于短期改不了代码的还有一个折中方案在系统层用兼容性开关做例外。但这属于技术债挂账不是长久之计而且每加一个例外就多一个需要记录和跟踪的隐患。5. 验证闭环从本机回环到外部扫描的三层确认改完配置重启服务浏览器能打开页面这只能证明 TLS 1.2 通了不能证明 TLS 1.0 被拒了。真正的验收必须做逐版本的否定测试——每个版本都要单独确认它失败了而不是笼统地确认某个版本成功了。5.1 本机逐版本握手测试的正确姿势我用得最多的是openssl s_client因为它可以精确指定协议版本而且输出信息足够详细# 测试 TLS 1.0期望失败 openssl s_client -connect 127.0.0.1:443 -tls1 -servername your.domain.local # 测试 TLS 1.1期望失败 openssl s_client -connect 127.0.0.1:443 -tls1_1 -servername your.domain.local # 测试 TLS 1.2期望成功 openssl s_client -connect 127.0.0.1:443 -tls1_2 -servername your.domain.local失败的输出通常会是alert handshake failure、no protocols available或者wrong version number成功的话会看到Verify return code和协商出来的协议版本。这里有个细节要注意加-servername参数是必须的因为 IIS 上是靠 SNI 来区分站点的不传这个参数可能会连到默认站点测出来的结果就不是你想要的那一个。Windows 环境下如果没装 openssl也可以用 PowerShell 的Tls12参数做简化测试# PowerShell 5.1 默认用 TLS 1.0/1.1能连上就说明旧协议还开着 try { Invoke-WebRequest -Uri https://127.0.0.1 -UseBasicParsing -TimeoutSec 10 | Out-Null Write-Host 旧协议仍可用 -ForegroundColor Red } catch { Write-Host 旧协议已被拒绝: $($_.Exception.Message) -ForegroundColor Green }这条命令的逻辑比较取巧PowerShell 5.1 的默认协议栈里包含 TLS 1.0所以在协议被禁掉之后它应该连接失败。如果它成功了说明关闭没有生效或者这台机器的 PowerShell 版本比较新7.x 默认走系统配置那就需要用-SslProtocol参数显式指定。5.2 外部视角的确认与两个常见误判本机测试通过之后从外部网络位置再做一次同样的测试这一步不能省。我遇到过两次本机测试通过、外部测试失败的情况原因一次是负载均衡设备对特定版本做了过滤另一次是中间的 WAF 拦了 TLS 1.0 握手并返回了自己的 alert导致从外部看起来像是服务端不支持实际上服务端的问题根本没解决。外部测试的工具选择上nmap的ssl-enum-ciphers脚本输出最直观nmap --script ssl-enum-ciphers -p 443 your.domain.com它会按协议版本分组列出每个版本支持的密码套件禁用的版本会明确标注。另一种误判是浏览器能打开就以为没问题。现代浏览器早就放弃了对 TLS 1.0 的支持它压根不会去尝试这个版本所以你用浏览器访问成功只能证明 TLS 1.2/1.3 正常对 1.0 是否被禁用没有任何信息量。这个逻辑关系一定要理清楚否则验收就是自欺欺人。5.3 怎么确认没有老客户端被挡在门外验证的另一面是确认该通的还通着。这部分不能靠主动探测只能靠日志。IIS 的 HTTPERR 日志和 Windows 系统日志里的 Schannel 事件是两个主要来源。Schannel 的握手失败事件在系统日志里事件源是Schannel事件 ID 通常是 36871创建安全通道时发生致命错误或者 36888。打开事件查看器按源过滤能看到失败的时间点和错误码。如果加固上线后这类事件量突然暴涨说明有大量客户端在用旧协议连接需要立刻评估是不是回滚。Get-WinEvent -FilterHashtable { LogName System ProviderName Schannel StartTime (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, Message | Format-List我的习惯是在上线后盯至少 24 小时的这个事件流尤其是业务高峰时段。有些老客户端不是全天在线比如某些定时任务、某些只在夜间跑的数据同步白天看着没事晚上才炸这是很典型的翻车模式。6. 上线之后最容易翻车的几类连接前面讲的都是怎么改和怎么验但这套改动真正的风险不在配置本身而在于它影响范围太广。这一节把我实际遇到过的事故按类型归一下方便你在动手前做一次针对性的自查。6.1 远程桌面、数据库、目录服务的连带影响这三个是我见过的最高频的连带故障源。远程桌面的情况比较微妙新版 Windows 的 RDP 客户端支持 TLS 1.2老版本尤其是某些精简版系统、某些第三方 RDP 客户端、移动端的老版本 App只支持 TLS 1.0。一旦服务端的 TLS 1.0 被禁这些客户端连上来会直接提示由于发生身份验证错误要求的函数不受支持或者干脆卡在连接中。所以动手前一定要确认所有需要远程管理这台机器的人用的是不是新版客户端。数据库连接的情况取决于实例版本。老版本的数据库实例在启用加密连接时协商能力可能只到 TLS 1.0这时候如果客户端强制走 TLS 1.2或者服务端禁了 1.0连接直接失败。这类问题往往不会在应用启动时就暴露而是等到某个走加密连接的模块被调用时才炸排查起来很费时间。目录服务的 LDAPS 是另一回事。如果这台 IIS 所在的机器需要向目录服务做加密查询而目录服务端还是老系统禁掉本机Client键的 TLS 1.0 之后这个查询会失败。表现是某些依赖身份认证的功能时好时坏日志里能看到 LDAP 相关的异常。注意这三类问题有一个共同特征——它们都不走 IIS 的 443 端口所以你在验证 HTTPS 站点的时候完全发现不了。做现状盘点时务必把这台机器上还有什么服务在监听端口作为必查项。6.2 出站调用报基础连接已关闭的排查链路这个报错是 .NET 出站请求失败时最常见的措辞但它背后的原因至少有四种必须按顺序排除第一步确认是协议协商失败还是证书校验失败。看异常的InnerException如果是AuthenticationException且消息里带SSL/TLS字样基本可以锁定协议问题如果是TrustFailure那是证书链的问题跟本次改动无关。第二步确认应用层有没有写死协议版本。在代码里搜SecurityProtocol或者用strings之类的工具在编译产物里找。这一步能排掉很大一部分改了配置没用的困惑。第三步确认系统的SystemDefaultTlsVersions和SchUseStrongCrypto是否两个分支都写了。只写 64 位分支而应用池是 32 位的这个组合我见过不止一次。第四步确认目标服务端到底支持什么版本。有时候问题不在你这边而是对方只支持 TLS 1.0你禁了之后自然连不上。这种情况下要么推动对方升级要么在出站方向上单独放行——但请注意Schannel 的协议开关是全局的没有只对某个目标放行的粒度真要这么做得靠应用层自己处理。6.3 回滚脚本与灰度分批的实操节奏回滚这事儿我坚持一个原则回滚脚本必须在改动之前就写好并测试过而不是出事之后现场手写。原因很简单出事的时候人都是慌的手写容易出错而且容易漏掉某个键。回滚的逻辑就是把前面所有设置反向操作一遍$protocols (TLS 1.0, TLS 1.1) $roles (Server, Client) $base HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols foreach ($proto in $protocols) { foreach ($role in $roles) { $path Join-Path $base $proto\$role if (Test-Path $path) { Set-ItemProperty -Path $path -Name Enabled -Value 1 -Type DWord Set-ItemProperty -Path $path -Name DisabledByDefault -Value 0 -Type DWord } } } Write-Host 已回滚协议开关请重启相关服务。灰度方面如果有多台服务器做负载均衡绝对不要一次全改。我的节奏是先改一台观察 24 到 48 小时重点看 Schannel 失败事件的数量和业务侧的错误率确认无异常后再改第二批比如 30%再观察最后全量。单机环境下没有灰度空间那就把观察期拉长并且提前和业务方约好可回滚的时间窗口。还有一点回滚不等于万事大吉。如果你已经改了两天期间有客户端尝试连接失败并被记录为业务异常那这些影响是既成事实。所以加固这件事最好挑业务低峰期做而且提前发个通知让依赖这台服务器的人有个心理准备。7. 几次加固下来我改掉的几个习惯最开始做这类加固我的习惯是看文档、改键值、重启、收工后来吃过几次亏现在流程完全反过来了。第一个改掉的习惯是不再相信改完重启就行。现在我一定会做逐版本的否定测试而且是从外部做的。因为本机测试有太多方式可以骗过你——回环地址走的路径、SNI 的默认站点、本机 hosts 文件的解析结果任何一个环节出问题测出来的都不是真实结果。第二个改掉的习惯是不再只备份要改的键。现在我导整棵SCHANNEL子树原因是有一次发现某个键被之前的人改过但改成了一个很奇怪的值如果不导全量根本看不出来。备份的意义不只是能恢复更是能对比。第三个改掉的习惯是不再把浏览器能打开当成验收通过。这个习惯最难改因为它太符合直觉了。但前面分析过现代浏览器根本不会去试 TLS 1.0浏览器能打开和旧协议被禁用之间没有因果关系。最后一个我现在会强制自己在动手前列一份这台机器上还有谁在用 TLS的清单。清单不长但每次列的时候都能发现一两个之前没想到的某个只在月底跑一次的报表同步任务、某个用来做监控告警的脚本、某个运维同事私自在上面装的小工具。这些东西不会主动告诉你它们依赖旧协议只会在你改完之后安静地坏掉。如果要说这套流程里最值得投入时间的一步我会选现状盘点。改配置本身十分钟就能搞定真正决定成败的是改之前你有没有搞清楚这台机器上到底跑着什么、连着谁、被谁连着。盘得清楚后面全是顺水推舟盘不清楚后面全是救火。
