问题不在于重新谈判；重新谈判所没有提供的是相信安全特性。

重新协商是在 SSL/TLS 连接中间进行新的握手。标准中对此进行了描述，尽管措辞不是很清楚，尤其是在定义重新谈判提供的保证时。

与客户端证书一起使用时，重新协商非常常见，尤其是与 IIS 一起使用时。事情是这样的：

• 服务器在 443 端口收到连接请求；它开始握手。服务器不要求提供客户端证书。
• 握手完成后，客户端会在 SSL 隧道中将实际目标 URL作为 HTTP 请求发送。到那时，服务器还不知道目标是哪个页面；他最多只知道预期的服务器名称（通过Server Name Indication）。既然服务器知道哪个页面是目标，他就知道要使用哪个“站点”（即服务器的一部分，在 IIS 术语中）。
• 如果特定站点需要或至少需要基于证书的客户端身份验证，则服务器会触发新的握手，这一次带有CertificateRequest消息。

这里的安全问题是层的问题。握手消息作为管理带外管理交互出现在“幕后”，围绕主要的“应用程序数据”流量，这只是 HTTP。一旦执行了新的握手，任何随后发送的应用程序数据都会被 SSL 的身份验证保护伞覆盖。但是，在第二次握手之前发送的应用程序数据是什么，特别是决定服务器执行第二次握手的初始 HTTP 请求，或者至关重要的是，在它之后（但在新握手之前）流水线化的其他 HTTP 请求？

碰巧的是，Web 服务器倾向于假设在第二次握手中刚刚执行的任何身份验证都可以追溯地“传输”到以前的数据。碰巧它不是真的。这在 SSL/TLS 标准中从未明确说明过，但这种身份验证仅以向前的方式起作用：没有时间旅行。上一段中的重要词是“随后”。这允许进行实际攻击（请参阅此页面以获取指向广泛解释的指针）。

实际攻击的一个关键点是第二次握手消息与新连接的握手消息（即“第一次握手”）无法区分。RFC 5746描述了该补丁，该补丁已在主要浏览器和服务器中实现（我们假设它们是最新的安全修复程序；否则，无论如何，您都会遇到大麻烦）。这也是 OpenSSL 报告为“安全重新协商”的内容。请注意，RFC 坦率地说：

虽然此扩展减轻了概述中描述的中间人攻击，但它并不能解决应用程序在不知道重新协商时可能面临的所有问题。

换句话说，这是一个修复已证明问题的补丁，但它并不声称涵盖所有理由。重新谈判真正提供的东西仍然没有在任何地方明确定义。如果您的客户端和服务器支持“安全重新协商”，那么现在一切正常（它可以防止所有当前已知的攻击）。重新谈判和交错握手的整个概念仍然非常需要更正式的分析。

到 2020 年，TLS 重新协商不再存在，因为它不安全。

• 重新协商从 2018 年的 TLS 1.3 开始被删除。
• 自 2009 年以来，所有主要软件都默认禁用重新协商（nginx、haproxy 等）。例如，请参阅 Apache SSLInsecureRenegotiation说明。
• 重新协商在设计上存在各种漏洞，迫使客户端将连接降级到比通常情况下更不安全的设置。
• 验证用于相互身份验证的客户端证书与重新协商分开处理。请参阅OpenSSL 中的SSL_verify_client_post_handshake()
• CVE-2009-3555所有实现，Mozilla 中的CVE-2011-5094，OpenSSL 中的CVE-2011-1473，Windows SSL 中的 CVE-2014-1771。

话虽这么说，但缺少 HTTP/2 或 TLS1/3 或两者的客户端身份验证支持似乎存在值得注意的问题。

• 如果您依赖客户端身份验证，最好进行广泛的测试并检查下面的错误报告。
• 铬：https ://bugs.chromium.org/p/chromium/issues/detail?id=911653
• 火狐：https ://bugzilla.mozilla.org/show_bug.cgi?id=1511989
• Python httplib：https ://bugs.python.org/issue37440
• TLS 1.2 客户端过去常常滥用重新协商来执行身份验证，但重新协商在 TLS 1.3 中完全消失了。必须升级客户端才能进行握手后身份验证。
• 由于流水线，HTTP/2 破坏了重新协商和握手后身份验证。待定的 RFC 8740 草案以标准化解决方法。

在重新协商期间，攻击者可以将信息注入连接。这里有详细描述。