问TLS_FALLBACK_SCSV是否提供全面的保护以防止降级攻击？

EN

TLS_FALLBACK_SCSV无法防止日志阻塞，其原因与实际工作的原因相同。这种反回退机制依赖于客户端将其放入ClientHello中，并最终成为计算最终Finished消息的哈希函数输入的一部分。只有当主动攻击者不能立即破坏握手密码，并实时修复Finished消息内容时，此操作才能工作。但是，这正是日志阻塞的结果:攻击者修改ClientHello消息，将导出RSA密码套件作为客户端套件的一部分，因此服务器接收的ClientHello不是客户端发送的内容。攻击者在执行此操作时，还可以修改ClientHello和ServerHello的其他部分，这些部分作为答案返回，例如修改公告的最大版本(从TLS 1.2到TLS 1.0)，并删除TLS_FALLBACK_SCSV。

事情是这样的：

• 客户端发送一个ClientHello，上面写着“TLS1.2，可以使用DHE，TLS_FALLBACK_SCSV”。
• 攻击者将其转换为一个ClientHello，上面写着“TLS1.0，只能使用DHE，不能使用TLS_FALLBACK_SCSV”。
• 服务器用一个ServerHello响应，上面写着"ok，TLS1.0，DHE，没有退路“。
• 攻击者再次将其更改为一个ServerHello，上面写着"ok，TLS 1.2，DHE，您的反回退已被看到并处理得很好“。
• 服务器以512位模数发送经过适当签名的导出DH参数.攻击者允许它们按原样流向客户端。
• 客户端期望“正常”DH参数，但它们与“导出”DH参数没有区别，除了模数大小之外，如果服务器似乎想要这样做，客户端完全乐意做弱DH (显然，有些Safari版本甚至同意使用16位模数.)。
• 握手继续进行，使用客户端和服务器双方都同意使用的512位模数(尽管其中一个认为它是“导出”而不是另一个)。
• 攻击者立即破坏它(由于它的小大小和可预测的模数)，从而获得客户端和服务器使用的会话密钥。
• 在握手结束时，客户端和服务器都计算应该发送和接收的Finished消息。他们看到了不同的握手消息(攻击者修改了ClientHello和ServerHello)，但攻击者当时拥有加密和MAC密钥，因此他可以随意解密、修补和重新加密Finished消息，以保持假象。

摘要: TLS_FALLBACK_SCSV是一种“反降级”机制，但它只覆盖协议版本，更重要的是，只有被降级的握手仍能抵御即时和完全破坏，它才能起作用。这对贵宾犬来说是很好的，因为只有在握手之后，加密消息才会受到攻击。但不是为了灌木塞。

至于异常情况，情况大致相同，只不过它依赖于客户端实现中的另一个错误:客户端必须接受使用服务器发送的临时密钥，尽管从客户端的角度来看，不应该发送这样的密钥，因为客户端没有要求导出RSA密码套件( SSL/TLS中没有使用临时RSA密钥对的非导出RSA密码套件)。

虽然这个问题很容易被认为是一个“协议缺陷”，其原因在于导出DH参数与非导出DH参数是无法区分的(这是Logjam攻击作者的观点)，但我自己的分析是，真正的问题是客户机和服务器都接受使用弱密码--服务器自愿支持DHE-导出，客户端接受以太短的模数做一些DH。

我相信你的推理是可靠的，只是有缺陷而已。

正如@SOJPM所指出的：

我认为SCSV可以防止协议降级攻击(f. ex )。TLS -> SSL)，而异常和日志阻塞攻击弱密码套件。- SOJPM

因此，TLS_FALLBACK_SCSV保护使用的协议，而不是密码套件。

您应该禁用导出密码、SSL、RC4等.由于简单的事实，您的其他方法依赖于客户端和服务器上的安全特性(如TLS_FALLBACK_SCSV机制)的正确实现。以及其他缓解措施。另外，这些机器中有一台超出了你的控制范围，你不应该依赖它是正确的，甚至是正确的。

禁用也是深度安全性的一部分(只允许针对大列表的一组选定的密码)和优化密码。(对于服务器来说，有限的集合比大集更容易优化，因为每个密码都需要自己的内存集。

不是的。

TLS_FALLBACK_SCSV不会为这个工作的。只是客户端说：“看，你让我第二次回来，还带着一个降级的协议版本！”

但是，僵局或怪胎不依赖于第二种连接。它适用于第一个连接。降级不是在协议级别上。它在传递的参数中。