Marsh Ray 的博客似乎马上就要关闭了，但您可以在Eric Rescorla 的博客（我在这里使用相同的示例应用程序数据）或此 PDF（archive.org 副本）中阅读更多内容。

• 真正的客户端向Client Hello服务器发送一个（GenCH），但这被 MITM 截获。

• Client HelloMITM 持有它并通过向服务器发送 aa (MitmCH) 来开始自己的握手。它正常完成握手并发送一些应用程序数据。例如：

  GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
  X-Ignore-This:
  

• MITM 现在将初始Client Hello(GenCH) 转发到服务器。

  就客户而言，这不是重新协商，而是初步协商。它无法区分。握手完成并发送自己的请求：

  GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
  Cookie: victimscookie
  

• 就服务器而言，接收第二个Client Hello(GenCH) 只是在与 (MitmCH) 发起的初始握手之后的重新协商（任何一方都可以在任何时间点发起 Client Hello）。应用层被视为连续的。这是服务器看到的：

  GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
  X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
  Cookie: victimscookie
  

通过这种方式，攻击者能够更改请求行（以及查询参数）并插入自己的标头，同时保留真正客户端的 cookie。MITM 无法查看或更改客户端发送的内容，但它能够添加之前的内容，这被视为应用层上同一请求的一部分。

概述。这是指几年前发现的与 SSL 重新协商相关的设计缺陷。该扩展旨在关闭漏洞。

背景。SSL 允许与服务器建立 SSL 会话的客户端请求重新协商会话参数：例如密码套件和其他安全参数。重新协商基本上会创建一个新的 SSL 会话，但可能比从头开始创建一个全新的 SSL 连接更有效。最关键的是，在重新协商的会话期间，客户端可以提供客户端证书，即使他最初没有提供。

因此，如果客户端发起重新协商，我们可以将 SSL 连接的时间线分为两个阶段：重新协商前的内容和重新协商后的内容。

攻击的先决条件。服务器仅在某些条件下容易受到这种攻击。举个简单的例子，假设服务器应用程序的编码方式是在重新协商的会话中检查客户端证书，如果找到，它将整个 SSL 连接视为来自该客户端的可信连接——包括在重新协商之前通过 SSL 连接发送的内容。从表面上看，这对于服务器应用程序来说似乎是一件非常可疑的事情，但假设我们的服务器应用程序被编码为这样做：将整个连接视为经过身份验证，即使客户端仅在后期提供任何身份验证 -重新谈判阶段。另外，让我们假设客户端将连接到服务器并使用客户端证书对服务器进行身份验证。

攻击。如果满足这些先决条件，则重新协商攻击是中间人 (MITM) 攻击。攻击将欺骗服务器关于攻击者发送的某些字节的来源：服务器将被愚弄以为它们来自客户端，而实际上它们来自攻击者。

攻击首先让攻击者打开到服务器的 SSL 连接并向服务器发送一些内容（攻击者将试图欺骗服务器，使其认为这些字节来自客户端）。现在，在某个时刻，客户端尝试连接到服务器，但由于这是 MITM 攻击，攻击者拦截了它。攻击者通过他与服务器的连接发起重新协商。在重新协商期间，攻击者在不修改消息的情况下从客户端和服务器来回传递信息。服务器认为它正在通过现有连接重新协商会话；客户端认为它正在完全打开一个新连接和新会话；但他们都没有发现他们观点中的这种不一致。在此期间，客户端使用其客户端证书进行身份验证。

在攻击结束时，让我们看看会发生什么。重新谈判成功。服务器成功验证了客户端的身份，并且知道客户端的身份对应于客户端的证书。客户端认为它已经完成了一个成功的 SSL 连接，并且不知道有什么不对劲。服务器看到一个经过成功重新协商的 SSL 连接，重新协商后的部分由客户端的证书进行身份验证。

现在，如果服务器错误地将整个 SSL 连接视为已通过客户端证书进行身份验证（正如我们在上面的先决条件中假设的那样），那么服务器将错误地认为在重新协商阶段发送的字节是由诚实的客户发送的。但实际上这些字节是由攻击者发送和控制的。所以攻击者欺骗了服务器关于这些消息的来源——身份验证的严重失败。

正如 Eric Rescorla 所说，“显然这不好，但这不是世界末日。 ”

解释。在这一点上，我们可以就谁应该受到指责进行辩论。是协议的错误，允许客户端和服务器最终处于他们对事件的看法不匹配的情况吗？或许。或者也许我们应该说这是服务器的错，因为做了一些愚蠢的事情，以至于将重新协商前的字节视为通过重新协商过程中发生的身份验证协议进行了身份验证，而实际上只有重新协商后的内容实际上是经过身份验证的通过它。

所以有三个可能的解决方法： 仔细编码你的服务器应用程序，这样他们就不会犯这个错误；更改服务器端 SSL 代码以拒绝所有重新协商请求；或更改协议使其不会发生，无论服务器应用程序如何设计。TLS 重新协商指示扩展遵循后一种方法。当然，如果你的服务器应用程序没有这个问题，那么扩展是无关紧要的。

问题的范围。 RFC 5746对可能出现这种情况的情况进行了一些讨论。例如，除了客户端证书之外，如果服务器应用程序根据客户端发送的一些秘密信息（如 HTTPS cookie）将客户端视为经过身份验证，也会出现这种情况。

据我所知，该扩展目前尚未广泛部署，但服务器可以通过简单地拒绝重新协商来防止该问题。

更多阅读。你可以在这里阅读更多：

• Eric Rescorla 对问题的出色描述

• 另一个很好的问题描述

• 针对不耐烦的 TLS 重新协商攻击

• CVE-2009-3555

• Mozilla 正在为这个问题做些什么

• 要查看您的服务器是否容易受到攻击，请尝试SSL Labs 的自动 SSL 配置测试器。他们的测试仪会自动测试这个问题。

（此漏洞假设您有中间人，或 MITM。我认为这是 MITM 在没有客户端私钥的情况下与服务器建立双向 SSL 连接的一种方式。您如何获得 MITM 情况是另一回事问题）。

您的客户端发送一个Client hello并等待服务器响应。客户端发送一些信息，包括一些将用于稍后建立会话密钥的随机值。这将永远发生。

该Client Hello由MITM好评。MITM 使用相同的方法自行Client Hello完成 SSL 设置。MITM 在不返回客户端的情况下响应。同时，客户端仍在等待服务器响应。请记住，我们欺骗了客户。他认为 MITM 是服务器。Server hello

所以此时我们有：

• 等待服务器响应的客户端 Server hello
• 与服务器具有完整 SSL 单向连接的 MITM

MITM 触发 SSL 重新协商或服务器请求它，可能是为了实现双向 SSL。无论哪种方式，MITM 都会处理重新协商请求。它发送Server Hello客户端一直在等待。但现在，MITM 控制着一切。无论服务器发送什么质询，MITM 都可以重放，以便客户端使用他的（客户端的）私钥计算所需的值。

现在我们有：

• 与 MITM 具有双向 SSL 会话的客户端，认为服务器响应
• 可以在客户端的通信通道中注入数据的 MITM。

通过禁用重新协商，服务器将在Server hello消息中请求客户端身份验证。MITM 将无法自行完成握手。