TLS为什么易受协议降级攻击？

#1 楼

简短答案：因为浏览器开发人员长期以来认为互操作性比安全性和标准遵从性更为重要。如果客户端尝试协商服务器不支持的协议版本，则连接将显示致命警报。这可能在握手协议中的三个步骤中的任何一个上发生：



服务器解析客户端问候时（该问候应该包含客户端支持的最高协议版本）。即使服务器不支持正确实现的服务器，也应存储客户端版本值。
解析包含RSA加密的主密码（该密码应包含服务器支持的最高协议版本）的客户端密钥交换消息时，客户端作为前两个八位位组）。此版本字段应与上面的客户端版本值进行比较，而不是与协商的版本进行比较。
在验证客户端完成消息（应该是所有握手消息的哈希，包括包含最高协议的客户端问候）时现在，如果服务器由于某种原因未按照TLS 1.0、1.1或1.2标准处理这些步骤，而是采用一种或另一种方式，例如要求客户端支持的最高协议版本具有特定值，或者不大于服务器支持的最高协议版本，客户端有两种选择：要么连接失败，要么向用户显示错误消息，或尝试在禁用最高协议版本的情况下再次连接。

如果客户端使用第二种替代方法（例如Chrome而不是IE 10），则有可能利用此漏洞。即使真实服务器确实支持TLS 1.1或TLS 1.2，并且真实服务器确实确实正确处理了客户端版本值，MITM仍可能利用该客户端不知道哪个服务器正确或不正确地处理了该客户端，并在两者中注入警报


编辑的说明：为了完整起见，我应该补充一点，我同意@Thomas的回答，即这在很大程度上应该不是问题，仅仅是因为：


一般来说，即使在利用此行为的MITM攻击下，客户端和服务器都无法协商未启用的协议版本，并且br />客户端和服务器都不应该启用不能提供足够安全性的协议版本。

根本的问题并不在于某些客户端以不受严格支持的方式协商协议版本按照标准，以便能够连接可能或可能存在的服务器不要以标准不严格支持的方式协商协议版本。

而是，在Carol可能连接到多台服务器的情况下可能会出现问题，但是对于与Sue的连接，仅需要TLS 1.2，对于所有其他服务器，SSL 3.0足够了。相反，Sue可能接受来自多个客户端的连接，但是只有来自Carol的连接才需要TLS 1.2。理想情况下，Carol和Sue应该能够依靠协议协商来确保自动协商TLS 1.2（在这种情况下，它们可能或可能不容易受到利用），但是正确的实现应确实检查TLS协商后，连接满足最低安全要求。

#2 楼

RFC 5246的附件E.1包含以下文本，该文本很好地总结了这种情况：


注意：已知某些服务器实现错误地实现了版本协商。例如，当客户端提供比TLS 1.0更高的版本时，有问题的TLS 1.0服务器会简单地关闭连接。另外，众所周知，如果ClientHello中包含任何TLS扩展，则某些服务器将拒绝连接。与此类错误服务器的互操作性是本文档讨论范围之外的一个复杂主题，并且可能要求客户端进行多次连接尝试。


对于单个连接，SSL / TLS包含必要的保护。反对版本回滚。也就是说，ClientHello消息包含client_version字段，该字段通告其受支持的最高版本，而ClientHello消息的完整内容（包括该字段）是哈希函数输入的一部分，该哈希函数用于在末尾计算Finished消息握手。这可以确保服务器看到“正确的值”，即与客户端相同。

关键点在于，它依赖于SSL 3.0的安全性，而不是TLS 1.2的安全性。这种防止回滚的保护措施不是因为协议的新版本是“受保护的”，而是因为旧版本已经包含了保护。它还要求旧标准（SSL 3.0）仍具有“足够稳健”的握手：执行版本回滚攻击（将客户端和服务器降回SSL 3.0）的攻击者必须具有完全破坏SSL 3.0的能力， Finished消息；否则，这些Finished消息将检测回滚。

SSL 2.0没有这样的基于散列的Finished消息（它具有验证消息，但是基于随机质询，而不是基于先前握手消息的内容），MitM攻击者可能会迫使客户端和服务器执行SSL 2.0而不是SSL 3.0，他们不会知道。与SSL 3.0相比，SSL 2.0没有“足够的保护”以防回滚，因此解决方案是在密码学可以保护它的地方走私等效的client_version字段（如SSL 3.0中所指定，这是在PKCS＃中完成的） 1个v1.5“类型2”填充，用于对premaster秘密进行RSA加密）。


版本回滚攻击是没有意义的；或至少可以这样争论。确实，任何版本回滚攻击都可以迫使客户端和服务器仅使用他们愿意使用的版本和算法。如果认为SSL 3.0较弱，那么客户端和服务器为什么会同意使用它？如果认为退回SSL 3.0是一个问题，则客户端注意到服务器显然无法处理TLS 1.x（因为x的任何值）将根本拒绝连接。相反，如果客户端接受使用SSL 3.0，那么SSL 3.0就可以了。 -基本功能，不应视为安全功能。如果客户端确实希望互操作性胜于安全性（如@Henrick解释），则没有真正的方法来阻止它。

例如，假设使用防回滚保护机制扩展了TLS。与SSL 2的情况一样，这要求在SSL 3.0握手消息中的某个地方走私true_client_version字段，而这种方式不能防止与旧的有问题的服务器（或旧的有问题的防火墙和入侵检测系统）互操作。不能使用扩展名（在ClientHello的末尾），因为此类扩展名是使旧的越野车服务器发生故障的一部分。但是，可以将值设置为client_random。该随机变量的长度为32个字节；前四个字节是当前时间，因此实际上有28个随机字节。 16个随机字节足以实现“随机性”；剩下12个字节可玩。可以指定client_random的最后12个字节应包含一个特定值，例如客户端支持的实际最新版本的6个连续副本。不了解此约定的客户端只有2-80的概率遵循此模式，并且旧的越野车服务器不应在此类client_random上中断。能够查看它是否正在与显然请求SSL 3.0或TLS 1.0的客户端通信，但是以这种秘密方式声称它可以执行TLS 1.2。然后，服务器将意识到一些犯规行为。但是，这可能是某些防火墙行为不正常的结果，从密码学家的角度来看，防火墙是攻击者，但从业务角度来看并非如此。老式的越野车系统比攻击更为常见。即使服务器决定在此时关闭连接，客户端仍可能会确定某些旧的有问题的防火墙阻止了TLS 1.2 ClientHello，然后再次尝试模仿SSL 3.0客户端-包括不对版本进行编码在client_random中，从而停用我们刚刚定义的防回滚系统。已经尝试建立多个连接以处理旧的错误服务器的Web浏览器可能会继续这样做。

总而言之，只要客户端真正想要连接，即使暗示要退回到SSL 3.0，并且服务器仍然接受与仅使用SSL 3.0的客户端进行通讯（因此无需任何反连接）后定义的回滚系统），则服务器上无法阻止它。如果那是通过防火墙和防回滚系统等所必需的，则客户端始终可以完美地模仿旧客户端。这并非特定于SSL。

在很大程度上，这也适用于SSL 2.0。 SSL 3.0中添加的防回滚系统仅作为一种过渡机制才有意义。如果SSL 2.0较弱，那么安全问题就不在于攻击者可以迫使客户端和服务器回退到SSL 2.0。真正的问题是客户端和服务器完全接受使用SSL 2.0。防止版本回滚攻击的真正方法是完全拒绝弱版本（如RFC 6176所建议）。