是否有任何基于CBC的加密套件对已知的攻击(如LUCKY13 )是安全的？

Question

如果您在https://mozilla.github.io/server-side-tls/ssl-config-generator/中选择现代配置文件，您可以看到它也建议启用以下四个密码套件。

• ECDHE-ECDSA-美学256-CBC 384(=TLS-ECDHE-ECDSA-WITH-AES-256-CBC-CBC 384)
• ECDHE-RSA-美学256-RSA 384(=TLS-ECDHE-RSA-WITH-AES-256 CBC-RSA 384)
• ECDHE-ECDSA-AES 128-128 256(=TLS-ECDHE-ECDSA-WITH-AES-128-CBC-128 256)
• ECDHE-RSA-AES 128-RSA 256(=TLS-ECDHE-RSA-WITH-AES-128-CBC-RSA 256)

根据互联网上的各种消息来源，如果你使用基于CBC的密码套件，像LUCKY13这样的攻击是可能的。(例如为什么TLS 1.3下降AES-CBC？ )

我的问题是，正如Mozilla在基于CBC的密码套件上面明确建议的那样，那些不容易受到LUCKY13攻击的密码套件，以及那些不受任何已知的此类攻击的密码套件是否安全？

Answer 1

不，所有的TLS CBC密码套件都有相同的问题:大多数旧的实现和少数当前部署的实现(有些是不可修补的，有些是研究人员无法联系到供应商的，等等)。有一个变体的lucky13或贵宾(两者都有许多命名的变种)。

Mozilla列表可能是在发现新的贵宾犬变体之前出现的，这最终导致SSL实验室测试人员将所有CBC密码套件标记为“弱”。

正确实现CBC密码套件是可能的，但难度太大。如果努力正确地实现它们，最好将精力用于支持GCM或CCM或Cha20-Poly1305。

如果对方能支持AEAD，你应该使用AEAD。如果对方不能支持AEAD，你必须非常怀疑，并彻底测试它的CBC。TLS应该是安全的，而不需要首先测试另一方，所以如果您可以放弃CBC支持，就应该这样做。这意味着您将对TLS版本的支持降低到1.2以下。

当然，出于商业原因，许多人会选择长期支持CBC密码套件。业务何时才能停止支持？当实践中没有这样的客户的时候。用户何时停止使用只能执行CBC的客户端(或代理)？当这样的客户端无法连接到重要的服务器(如google、facebook)时。这需要很长时间。

对于明年需要CBC密码套件的站点，Chrome可能会显示出“不安全”的UI，但完全放弃它们--我想没有。Google的服务器不能显示不安全的UI --它们要么允许连接，要么不允许连接，所以我认为它们将允许与CBC密码套件的连接很长一段时间(尽管它们有已发布，它们希望人们升级到AEAD，并且只承诺用AEAD支持ECDHE )。

Answer 2

幸运13适用于所有使用CBC的密码套件，不管它们还使用什么。攻击完全针对CBC以及TLS中使用CBC的方式，与协议的其他功能无关。

对幸运的13有几个防御，但没有一个是万能的。

• 原则上，Lucky 13是对TLS实现的攻击，而不是对协议本身的攻击。实现基于TLS的密码套件的方式是可能，以防止Lucky 13。问题是这样做非常困难，而且会带来很大的性能损失。我认为OpenSSL的缓解完全可以抵御攻击(并支付性能成本)(请注意，尝试了几次)，但并不是所有的TLS实现都这样做。在这种情况下，“只更新您的软件”可能解决不了问题。
• 加密-然后-MAC扩展完全防御幸运十三或其他任何可能出现的CBC填充神谕。它需要在服务器和客户端上都得到支持。问题是，并不是所有的TLS实现都支持它，而且大多数软件都不允许您配置TLS密码套件来表示“只有在启用EtM时才允许使用此密码套件”。
• 当然，最好的防御方法是禁用所有CBC密码套件，并且只使用AEAD (这需要TLS 1.2或更高版本)。然而，并不是所有的客户端和服务器都支持AEAD密码套件。在互联网上，2017年年中至2018年年中，使用AEAD (即双方都支持AEAD)的TLS连接的比例停滞在85%左右(资料来源：时代的来临: TLS部署的纵向研究 using .2；关于测量数据的收集方式，见§3 )。