如果服务器不支持 TLS_FALLBACK_SCSV 以防止降级攻击,Ssllabs 不会给出 A+(最高)评级。但我想知道,如果服务器仅合法地为 3 个最新版本的 TLS 提供支持,这真的有用吗?所以降级最多将实现 TLS 1.0,这无论如何都足以支持旧浏览器。
更有趣的是,如果服务器仅支持例如 TLS 1.2,那么这种保护完全没用,或者我不明白这里的某些内容?
如果服务器不支持 TLS_FALLBACK_SCSV 以防止降级攻击,Ssllabs 不会给出 A+(最高)评级。但我想知道,如果服务器仅合法地为 3 个最新版本的 TLS 提供支持,这真的有用吗?所以降级最多将实现 TLS 1.0,这无论如何都足以支持旧浏览器。
更有趣的是,如果服务器仅支持例如 TLS 1.2,那么这种保护完全没用,或者我不明白这里的某些内容?
整个分级机制更多的是宣传和公关,而不是实际的安全。如果您想要良好的安全性,那么您必须注意细节并了解事情的内部运作方式。如果你想要一个好成绩,那么你应该尽一切努力取得好成绩。SSL Labs 的“A+”是在报告末尾添加的非常漂亮的东西,但它并不真正等同于拥有坚如磐石的安全性。拥有“A+”就等于能够说“我拥有 A+”。
SSL/TLS 握手的原理是客户端和服务器公布它们支持的最大版本,这样选择的版本确实是客户端和服务器都支持的最新版本。只要主动攻击者不能立即(实时)中断客户端和服务器都支持的任何版本的握手,此属性就成立。例如,客户端和服务器可以支持从 SSL 3.0 到 TLS 1.2 的所有版本(TLS 1.2 在内部是“SSL 3.3”),并且攻击者无法强制降级,因为即使 SSL 3.0 握手也足够强大,不会被主动攻击者立即破坏- 握手包括广告的最高版本。
...除非客户在做一些愚蠢的事情,即重新连接和宣传低于他们实际支持的版本。现有的客户端这样做是因为有些客户端必须与做一些更愚蠢的事情的服务器通信,每当客户端发布的版本高于服务器听说过的最高版本时,服务器就会崩溃/断开连接。通常,当客户端说“SSL 3.42”而服务器只知道“SSL 3.17”时,服务器应该回答“我们将使用 SSL 3.17”。SSL 3.0 及更高版本的标准和文档在该主题上一直非常清楚。但是开发人员仍然弄错了;一些服务器,当他们收到“SSL 3.42”时,只是干瘪,当场死亡。
因此,为了应对可能不称职的服务器,客户端已经养成了在连接错误的情况下自动设置自己的习惯。这就是TLS_FALLBACK_SCSV发挥作用的地方:它是一种额外的机制,以密码套件的名义在握手中走私,以便客户端可以告诉服务器“顺便说一句,我并不愚蠢,我只是发送一个愚蠢的ClientHello
以防您作为服务器成为这些在不协调时间爆炸的错误服务器之一。”
如果客户端应用了自动哑铃并且不支持 TLS_FALLBACK_SCSV,那么服务器将无法防止降级攻击:攻击者将能够通过简单地杀死尝试做广告的连接来强制客户端使用旧协议版本任何更新的东西。但是,如果客户端和服务器支持 TLS_FALLBACK_SCSV,那么它们将检测到任何降级尝试。
这个长长的序言只是为了获得回答你问题的背景。基本上,如果您的服务器不支持 TLS_FALLBACK_SCSV,那么主动攻击者将能够强制降级,即使客户端支持 TLS_FALLBACK_SCSV。这是一个问题,如果您支持 TLS 1.0、TLS 1.1 和 TLS 1.2,那么这是有原因的:您更喜欢在可用时使用 TLS 1.2,所以如果攻击者有办法阻止这种情况,那么这就是严格的sensu,一次成功的攻击:攻击者可以强迫一种与首选的、未受攻击的情况不同的情况。
现在这并不意味着后果很严重。TLS 1.0 有一些已知的缺点,基本上归结为两种攻击:
使用选择明文的类 BEAST 攻击利用以下事实:在 TLS 1.0 中,使用基于 CBC 的密码套件,攻击者可以预测下一条记录的 IV;
例如,填充预言机攻击依赖于处理传入记录的微小时间差异(描述为“幸运 13 攻击”)。
TLS 1.1 修复了第一种,每个记录不可预测的 IV;对于第二次攻击,TLS 1.2 提供了根本不需要填充的 AEAD 密码套件,从而避免了任何填充预言。但是,通过对基于 CBC 的密码套件使用“1/n-1 拆分”以及使用恒定时间 MAC 计算,可以在“纯”TLS 1.0 中有效地缓解这两种攻击。
因此,如果客户端开发得足够好,可以进行 1/n-1 拆分,并且服务器开发得足够好,可以在恒定时间内计算 MAC,那么据我们所知,使用 TLS 1.0 不会导致安全问题需要修复。有人可能会争辩说,实现 TLS_FALLBACK_SCSV 的客户端和服务器必须是最新的,并且“可能”是最新的实现建议,因此他们很有可能正确地做所有事情并能够运行安全的 TLS 1.0。
但是,总是有人怀疑支持 TLS_FALLBACK_SCSV 的服务器可能仅支持它以从 SSL Labs 获得 A+,并且可能没有努力进行恒定时间 MAC 计算,因为 SSL Labs 无法轻易测试常数-时间计算。
总结一下:不支持 TLS_FALLBACK_SCSV 不一定是一个严重的问题,这取决于客户端和服务器实现 TLS 1.0 的程度(通过不支持 SSL 3.0,您已经避免了最明显的问题)。但是,不能保证良好的实现,不支持 TLS_FALLBACK_SCSV 在形式上是一个弱点,即使它不一定是一个漏洞。攻击者不能将弱点转化为充分利用并不意味着它不存在。
在任何情况下,您都不会实现 TLS_FALLBACK_SCSV,因为您需要安全性;您将实施 TLS_FALLBACK_SCSV,因为您想要 A+。如果您不这样做,那么您将花费过多的时间向许多人解释“A+”等级在这方面毫无意义,并且您可以承受不接受它的代价。从长远来看,不与狼嚎叫太昂贵了。