MS10-049：深入解析CVE-2009-3555 TLS重协商漏洞

该漏洞由安全研究人员Marsh Ray和Steve Dispensa发现。漏洞成因在于某些受传输层安全（TLS）/安全套接层（SSL）保护的协议错误假设TLS重协商后接收的数据仍来自同一客户端。重协商是TLS允许任一端更改安全会话参数的功能。本文将解释我们的修复方案工作原理，以及为何对多数微软客户风险有限。

TLS和SSL未能有效保证这种真实性，导致底层协议需要确保重协商会话仍与同一对端进行——而协议往往缺乏相应准备。能够拦截流量的攻击者（例如通过ARP欺骗攻击或DNS缓存投毒）可执行中间人攻击，拦截TLS重协商尝试，并部分伪装成认证客户端。

研究人员通过巧妙操纵协议发现：作为中间人，他们可保持客户端连接停滞，启动与服务器的重协商并提交数据。服务器接收后，他们会重启重协商，并将服务器的重协商尝试传回客户端，仿佛未发生任何异常。虽然攻击者无法借此更改或读取加密信息，但可在安全连接前预置数据。

某些协议受影响更严重。例如HTTPS会受影响：攻击者可从客户端向服务器发送HTTPS请求，通过请求拼接使实际客户端传送认证cookie。服务器将读取攻击者发出的请求，并将其归因于已认证客户端。

总体而言，对多数微软客户的风险有限。虽然所有厂商的TLS/SSL实现均受影响，但客户整体风险较低。要利用此漏洞，攻击者需滥用已在对等端间进行的TLS重协商。Internet Information Services（IIS）6和7不允许客户端发起TLS重协商，从而消除了攻击者诱发漏洞场景的能力。这些服务器仅在配置为“接受”基于证书的双向认证时才会自行启动重协商——这是非默认场景。此外，团队还发现此漏洞难以利用的其他原因。我们在2月博客文章中发布了整体风险评估的更多细节。

需注意：这对某些部署仍可能是重要问题，应安装更新。特别是漏洞可能影响其他鲜为人知的非HTTP协议。漏洞确认后，微软通过互联网安全促进行业联盟（ICASI）协作，确保提供与第三方TLS实现兼容的TLS层修复方案。

该协作及IETF TLS工作组中许多安全开发者的辛勤工作，促成了RFC 5746（TLS重协商指示扩展）的发布。此新标准由Windows安全工程团队的Nasko Oskov合著，通过定义加密绑定重协商与初始TLS连接的TLS扩展来解决漏洞。安装此修复后，TLS端点自身可验证发送的数据是否仍属于同一初始连接，不再需要封装协议执行此操作。

要为连接提供完全保护，客户端和服务器均需具备符合RFC 5746的TLS实现。截至目前，我们很高兴宣布微软客户可获得部署此新功能的更新。许多其他厂商也已发布或正在发布对此扩展的支持。

我们理解管理员可能需要要求客户端安装更新才能连接高安全性应用。KB 980436中记录的注册表项允许管理员将系统置于“兼容”或“严格”模式。在默认的兼容模式下，客户端将启用但不强制使用此TLS扩展。未安装安全更新的客户端仍可成功与未更新的对端连接。在严格模式下，双方均需符合标准才能成功连接。

下图更详细展示了此机制：

（图表位置）

致谢

感谢以下人员对此问题的工作及博客反馈：

• Windows安全工程的Nasko Oskov
• MSRC工程的Gavin Thomas和Robert Hensing
• Windows持续工程的Manoj Thakur和Chunlin Shi

致意， -Maarten Van Horenbeeck，MSRC项目经理