服务器不支持TLS重新协商修正

缓解是指一种设置、通用配置或者一般的最佳实践，它以默认状态存在，能够降低利用漏洞的严重性。 以下缓解因素在您遇到的情形中可能会有所帮助：

• 网站不通过 SSL 托管内容，只通过不受影响的 HTTP（明文）连接提供内容。
• Internet Information Services (IIS) 6 和 IIS 7 不允许客户端发起的重新协商。 这可以显著减少攻击面。 使用不太可能对用户键入的用户名和密码进行攻击的 SSL 站点。 当用户端证书用于执行相互身份验证时，最有可能出现通过 IIS 6 和 IIS 7 进行欺骗的情形。 此情形并不常见。
• 只有当攻击者能够通过利用其他漏洞（如本地子网攻击或 DNS 欺骗）成功地执行中间人攻击时，客户才会受到影响。

变通办法是指一种设置或配置更改，它不能从根本上纠正漏洞，但有助于在应用更新之前封堵已知的攻击源。 Microsoft 已测试了以下变通方法，并在讨论中指明了变通方法是否会降低功能性：

• 在 IIS 6 和更高版本上启用 SSLAlwaysNegoClientCert运行 IIS 6 和更高版本的 Web 服务器会受到影响，因为它们通过请求客户端证书来要求执行相互身份验证，可以通过启用 SSLAlwaysNegoClientCert 设置进行加固。 这将导致 IIS 在初始连接时提示客户端提供证书，不需要由服务器发起的重新协商。

  变通办法的影响： 设置此标志将要求客户端先执行身份验证，才能从受 SSL 保护的网站加载任何元素。 这将导致浏览器在连接到受 SSL 保护的网站时始终提示用户提供客户端证书。 如果受 SSL 保护的内容不需要相互身份验证，则收到提示选择证书的用户只需要取消该对话框以查看 SSL 连接上的内容，而不必选择要用来执行身份验证的证书。

  对于 IIS 6：

  在提升的/管理员命令提示符处从“c:\inetpub\adminscripts”文件夹中运行下列命令：

  adsutil.vbs SET w3svc/<N>/SSLAlwaysNegoClientCert true

  其中 <N> 代表要配置的网站编号（例如，“默认网站”为 1，下一网站为 2 等等）。 例如：要保护 IIS 创建的“默认网站”，应使用下列命令：

  adsutil.vbs SET w3svc/1/SSLAlwaysNegoClientCert true

  对于 IIS 7：

  将下列文本保存到 Enable_SSL_Renegotiate_Workaround.js 文件中

  var vdirObj=GetObject("IIS://localhost/W3svc/1");
// replace 1 on this line with the number of the web site you wish to configure

  WScript.Echo("Value of SSLAlwaysNegoClientCert Before: " + vdirObj.SSLAlwaysNegoClientCert);
vdirObj.Put("SSLAlwaysNegoClientCert", true);
vdirObj.SetInfo();
WScript.Echo("Value of SSLAlwaysNegoClientCert After: " + vdirObj.SSLAlwaysNegoClientCert);

  从提升的/管理员命令提示符处运行下列命令：

  cscript.exe enable_ssl_renegotiate_workaround.js

此漏洞的影响范围有多大？
此漏洞是欺骗漏洞。 成功利用此漏洞的攻击者能够在受保护的 TLS/SSL 连接上引入信息，从而有效发送流量来欺骗经验证的客户端。

造成漏洞的原因是什么？
RFC 2246 中所述的 TLS 协议介绍了重新协商功能，该功能允许任一对等端任何时间点重新协商受保护的连接的参数。 能够利用其他攻击（如 DNS 欺骗或本地子网攻击）成为连接中间人的攻击者可能滥用此类重新协商功能，将应用程序特定的命令预先设计到正在建立的有效的 TLS 会话中。

特定情况下，服务器可能在经过 TLS/SSL 验证的客户端的上下文中执行那些命令。 在 Windows 中，TLS 和 SSL 通过安全通道 (SChannel) 安全程序包实施。

为什么 IIS 6.0 和更高版本的默认安装不受此漏洞的影响？
只有当任一连接对等端能够重新协商 TLS/SSL 参数时，此漏洞才会被利用。 IIS 可防止任何由客户端发起的 TLS/SSL 重新协商。 此外，当配置为使用基于证书的相互身份验证（这不是默认设置）时，IIS 只会发起服务器重新协商尝试。

请注意，如果在某个部署中，实际 TLS/SSL 连接不在 IIS 服务器上直接终止，而在第三方 SSL 终结器或反向代理上终止，则连接可能仍易受此漏洞的影响。