该漏洞适用于以下情况：

• 攻击者可以在网络级别进行中间人攻击（通常通过DNS 中毒或通过操作虚假的开放 WiFi 接入点）。
• 网站通过 HTTPS 提供一些服务。
• 网站的某些部分需要用户身份验证。
• Web 服务器接受 SSL/TLS 重新协商。
• Web 服务器已准备好对先前的请求追溯应用身份验证。

最后一点是关键。为了理解它，让我们看看攻击是如何进行的：

• 客户端（受害者）C想要连接到服务器S。但是，攻击者A在TCP级别拦截了连接并自己应答。
• 客户端 C 将其ClientHelloSSL/TLS 消息发送给攻击者。
• 攻击者作为客户端连接到服务器 S。然后攻击者继续与服务器进行正常的 SSL/TLS 握手。
• 攻击者将命令 X 注入服务器 S（需要用户身份验证的命令类型）。
• 不知何故，触发了重新协商：这是一个新的握手，包含消息，在已经建立的 A->S SSL 连接中执行。
• 对于该重新协商，攻击者只需ClientHello从客户端 C（仍在等待）发送消息，并在客户端和服务器之间来回转发后续消息。这里的巧妙之处在于，从客户端的角度来看，握手是第一次握手，但从服务器的角度来看是重新协商。
• 在握手期间或握手之后，服务器对客户端进行身份验证；然后，不知何故，服务器只是假设它一直在与同一个客户端通信，并将该身份验证应用于它在重新协商之前收到的命令 X。服务器以客户端 C 的名义执行命令 X，而该命令是由攻击者注入的。

这怎么会发生？重要的一点是，服务器从此时是未经身份验证的客户端接收命令 X，但不会立即执行它。服务器等待重新协商发生，然后进行某种身份验证，然后才处理命令。在 HTTPS 请求中，只有当服务器自己触发重新协商并期望第二次握手提供身份验证时，才会真正发生这种情况。这与 HTTPS 的分层特性有关：它是 HTTP-within-SSL，因此在 SSL 级别发生的所有事情对于 HTTP 层都是透明的。一旦收到 HTTP 请求 X，服务器就会延迟响应，直到所有 SSL 级别的任务都已执行。

因此，在实践中，使用客户端证书时会发生这种情况。这是 Microsoft IIS 的典型运行方式：

• 客户端连接到服务器。在第一次握手期间，服务器知道客户端在目标 URL 中看到的服务器名称（通过服务器名称指示扩展），但不知道 URL。服务器不请求客户端证书。
• 当第一次握手完成后，客户端发送实际的 HTTP 请求。在那个时候，并且只有在那个时候，服务器才知道目标 URL 以及完整的路径和参数。服务器然后意识到该请求是针对需要基于证书的客户端身份验证的站点的一部分。
• 在响应请求之前，服务器触发重新协商；这一次，服务器要求提供客户端证书。
• 在第二次握手之后，服务器知道它正在与正确的客户端通信，并执行 HTTP 请求。

IIS 仅在特定路径上请求客户端证书，而不是针对完整的服务器，这主要是因为浏览器为用户证书选择提供的用户界面在美学上并不理想。事实上，它们对于普通用户来说是彻头彻尾的恐惧。用户证书很少见；很少有服务器与他们一起工作。

因此，适用 TLS 重新协商漏洞的唯一可能的情况是需要客户端证书的 Web 服务器，它的工作方式与 IIS 类似。如果您不使用基于证书的客户端身份验证，则该漏洞不是问题（至少，我认为无法利用此漏洞）。另一方面，如果您确实使用客户端证书，那么该漏洞是一个非常严重的漏洞并且不难利用（只需要100 美元的设备）。因此，所涉及的风险要么是“无”，要么是“高”，这取决于像 nessus 这样的工具无法自动猜测的系统架构特征；nessus 然后以“medium”响应，在这种情况下，它实际上是“depends”或“maybe”。

请注意，漏洞来自于相同的握手消息用于初始握手和重新协商的事实。该漏洞的修复确实是一种将ClientHello消息明确标记为“初始”或“重新协商”的方法，以便服务器可以检测到恶意行为。但它只有在客户端和服务器都支持它时才有效，并且服务器拒绝与不支持该扩展的客户端对话。Nessus 告诉您，您的服务器接受与不支持扩展的客户端通信，因此可能存在漏洞（取决于服务器是否需要 IIS 方式的客户端证书）。有一个权衡：通过强制扩展支持，服务器在某些情况下增加了保护，但也破坏了与旧旧浏览器的兼容性（这可能是也可能不是一个可取的事情）。

从概念的角度来看，真正的问题是 SSL/TLS 标准描述了重新协商，但从未解释通过它真正实现了哪些安全特性。IIS 只是错误地假设追溯身份验证是这些特征的一部分。

我的假设是这与此 CVE 有关：

CVE和 CVE 详细信息

许多组织已经发布了有关此漏洞的确认信息，因此可以利用它。我没有找到任何 metasploit 模块，但这对合法攻击者来说意义不大。

由于这是在 2009 年，大多数现代系统都有补丁。我会尝试以不同的方式呈现这一点，而不是告诉客户这被列为中等漏洞，但您认为它是低漏洞。

我不会给人的印象是这没什么大不了的，将其视为中等漏洞（并验证漏洞是否存在），评估客户威胁，如果他们主要来自滑梯，我可以看到通知客户低被剥削的风险，但是如果您的客户确实有可能受到合法人员的攻击，我会原样离开。

最后，根据我的经验，客户倾向于拖延低风险项目，如果您决定将其作为低风险项目呈现，我会强调存在更新，并且应该为系统打补丁。