TLS_FALLBACK_SCSV 无法防止 Logjam，原因与 Logjam 实际工作的原因相同。该防回退机制依赖于客户端将其放入 中ClientHello，并最终成为计算最终Finished消息的哈希函数的输入的一部分。这只有在主动攻击者不能立即破解握手加密并实时修复Finished消息内容时才有效。但这正是 Logjam 发生的情况：攻击者修改ClientHello消息以将导出 RSA 密码套件作为客户端套件的一部分包含在内，因此ClientHello服务器接收到的不是客户端发送的。当他在这的时候，攻击者也可以修改其他部分ClientHello和ServerHello 作为答案返回，例如修改广告的最大版本（从 TLS 1.2 到 TLS 1.0）并删除 TLS_FALLBACK_SCSV。

事情是这样的：

• 客户端发送一条ClientHello内容为“TLS 1.2，可以使用 DHE-RSA，TLS_FALLBACK_SCSV”。
• 攻击者将其更改为ClientHello“TLS 1.0，只能使用 DHE-EXPORT-RSA，不能使用 TLS_FALLBACK_SCSV”。
• 服务器以ServerHello“ok, TLS 1.0, DHE-EXPORT-RSA, no fallback”作为响应。
• 攻击者再次将其更改为ServerHello“好的，TLS 1.2，DHE-RSA，您的反回退已被看到并得到很好的处理”。
• 服务器使用 512 位模数发送经过正式签名的导出DH 参数。攻击者让它们按原样流向客户端。
• 客户端期望“正常”DH 参数，但除了模数大小外，它们与“导出”DH 参数没有区别，如果服务器似乎想要这样做，客户端对执行弱 DH 完全满意（显然，一些 Safari版本甚至同意使用 16 位模数...）。
• 握手继续，使用客户端和服务器都同意使用的这个 512 位模数（尽管其中一个认为它是“导出”而不是另一个）。
• 攻击者立即破解它（由于它的小尺寸和可预测的模数），从而获得客户端和服务器使用的会话密钥。
• 在握手结束时，客户端和服务器都会计算Finished它们应该发送和接收的消息。他们看到了不同的握手消息（攻击者修改了ClientHello和ServerHelloFinished

总结： TLS_FALLBACK_SCSV 是一种“防降级”机制，但它仅涵盖协议版本，更重要的是，它仅在降级后的握手仍然能够抵御立即和完全破坏的情况下起作用。这对 POODLE 来说很好，攻击只发生在握手之后，发送加密消息时。但不适用于 Logjam。

至于 FREAK，大致相同，只是它依赖于客户端实现中的另一个错误：客户端必须接受使用服务器发送的临时密钥，即使从客户端的角度来看，没有这样的应该发送密钥，因为客户端没有要求导出 RSA 密码套件（在 SSL/TLS 中没有非导出 RSA 密码套件仍然使用临时 RSA 密钥对）。

虽然很容易说问题是“协议缺陷”并且在于导出 DH 参数与非导出 DH 参数无法区分（这是 Logjam 攻击作者的观点），但我自己的分析真正的问题是客户端和服务器都接受使用弱加密——服务器愿意支持 DHE 导出，客户端接受以太短的模数进行一些 DH。

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

正如@SOJPM 指出的：

我认为 SCSV 可以防止协议降级攻击（例如 TLS -> SSL），而 FREAK 和 Logjam 攻击弱密码套件。– SOJPM

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

您应该 禁用导出密码、SSL、RC4 等...因为一个简单的事实是您的其他方式依赖于客户端和服务器上的安全功能（如 TLS_FALLBACK_SCSV机制）的正确实现。和其他缓解措施。此外，其中一台机器不在您的控制范围内，您不应依赖它是否正确甚至正确。

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

不
，TLS_FALLBACK_SCSV 不适用于此。只是客户说“看，你让我第二次回来，而且协议版本降级了！”

但是 Logjam 或 FREAK 不依赖于第二个连接。它适用于第一个连接。降级不在协议级别。它在传递的参数中。