TLS_FALLBACK_SCSV有什么帮助？

Question

在阅读了https://datatracker.ietf.org/doc/html/draft-ietf-tls-downgrade-scsv-0之后，我可以理解，当您拥有只支持SSLv3的遗留SSL服务器时，将重新建议使用此选项。

但是即使在阅读了几篇文章之后，也无法理解这个选项是如何起作用的。

有人能帮我理解这件事吗？

Answer 1

在一个更好的世界里，TLS_FALLBACK_SCSV是不必要的: SSL从至少SSL3.0开始就一直支持防降级版本协商，所以处于中间的人永远不应该将连接限制在比相互支持的最大值更早的版本上。

但是，有些损坏的服务器并不真正支持这种版本协商；只需在ClientHello中接收一个未知的、更新的、版本号或未知的TLS扩展就会导致它们崩溃。(兼容的服务器不会崩溃，只需告诉客户端他们希望使用协议的较低版本；连接将使用最高的相互支持版本建立。)

理想情况下，客户端只需拒绝连接到这些损坏的服务器；服务器供应商将迅速解决问题，并恢复适当的版本协商。

事实证明，相当多的服务器供应商或管理员不愿意这样做。许多浏览器现在将试图通过使用不触发错误服务器行为的“遗留”ClientHello连接来解决问题，这实际上是仅使用SSL3.0进行的第二次连接尝试。

不幸的是，这为处于中间的人打开了一种攻击可能性:通过简单地阻止使用新的TLS版本到服务器的客户端连接尝试，并模拟服务器对客户端的错误服务器响应，它们强制进行SSL 3.0连接尝试；使用SSL 3.0的连接将最终建立，服务器认为客户端使用的是一个非常旧的SSL库，而客户端认为它正在与错误的SSL-3.0(仅限于服务器)对话。

本质上，TLS_FALLBACK_SCSV允许客户端在降级连接尝试中发送隐藏版本号，这种方式不会触发服务器错误。

非正式地说，所传达的信息可解释如下：

嗨，服务器，尽管我只声称在版本头中支持TLS版本x，但实际上我一直支持TLS版本直到y。如果您支持比x更好的东西，这意味着这里正在发生一些不祥的事情！

实际上，向后兼容的信号是一个特殊的“虚拟”密码套件，它将被不支持备份预防的服务器所忽略(不管它们是中断的SSL3.0还是最近的TLS 1.2服务器)。

只有支持草案规范的服务器才能解释信号并采取相应的行动；较老的服务器只会认为客户端支持一些他们不知道的额外密码套件，并将一如既往地继续握手。