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


解决方案 (更新补丁并重启服务器使其生效):

http://support.microsoft.com/kb/980436

http://www.microsoft.com/technet/security/bulletin/ms10-049.mspx

 

TLS/SSL 重新协商漏洞 (CVE-2009-3555) 的缓解因素

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

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

TLS/SSL重新协商漏洞 (CVE-2009-3555) 的变通办法

变通办法是指一种设置或配置更改,它不能从根本上纠正漏洞,但有助于在应用更新之前封堵已知的攻击源。 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 重新协商漏洞 (CVE-2009-3555) 的常见问题解答

此漏洞的影响范围有多大?
此漏洞是欺骗漏洞。 成功利用此漏洞的攻击者能够在受保护的 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 终结器或反向代理上终止,则连接可能仍易受此漏洞的影响。

免备案空间专题