我正在观看有关 TLS 1.3的视频：“部署 TLS 1.3：好坏参半 (33c3) ”，看到他们努力提供
“更少，更好的选择”
他们放弃了AES-CBC作为支持的分组密码模式。
该视频列出了一些攻击（Lucky13、POODLE 等），在我未经训练的眼睛看来，这似乎是实施问题。我知道最好有一种不鼓励此类实现问题的模式，但是是否只需要弃用整个密码模式？
虽然这本书有些过时（2010 年），但Cryptography Engineering它推荐使用随机生成的 IV 作为最佳选择的 AES-CBC。
这里的问题不在于 CBC，而在于更容易安全实施且不会失去数学安全性的替代方案。事实上，众所周知，AES-CBC 难以正确实施。我记得传输层安全的旧实现没有加密安全初始化向量，这是 CBC 模式的必备条件
最近的很多攻击都是填充预言机攻击，例如Bleichenbacher 攻击。这些尤其依赖于为支持而保留的旧模式。POODLE 是一个降级漏洞。LOGJAM 正在将 TLS 降级为旧的出口级（读取 NSA 破坏）加密套件。
对于 CBC 模式，存在 Vaudenay 攻击。这些攻击依赖于服务器明确表示“无效填充”，从而在每个事务中泄露 1 位信息。错误消息已删除，但时间问题仍然存在。如果填充有效，服务器在响应之前仍然使用更多时间。
作为回应，他们被迫提出了一种特殊的解决方法，即生成一个虚拟密钥，并使用它进行解密，这样它在实现的另一部分就会失败。在每个实施中。所以他们决定不再通过在规范中支持它来强迫开发人员这样做。
密码学是一个非常广泛的领域，它本身就是一门专业。历史从不愉快的经历中学到，即使是该领域的佼佼者，也几乎无法保证完美地做到这一点。例如，由 RSA 的共同发明者（和部分同名）Ron Rivest 创建的 MD5 被广泛使用，然后在 2013 年被打破。它的抗碰撞性在 2^18 时间内被规避，在 128 位散列的台式计算机上不到一秒。
如果正确实施，CBC 是一种很好的加密模式。短短一句话，我就指出了CBC的两个缺陷。
如果它很难正确实现，最好不要被协议允许。密码学设计正慢慢地从拥有一些经过充分研究的、灵活的原语转向拥有一些经过充分研究的、健壮的原语，因为在实践中，问题不是人们不能做他们想做的事，而是更多的是他们做事这在名义情况下有效，但会受到攻击。
基本上，Lucky13 发生了，结果非常糟糕：Amazon s2n 认为他们修复了它，但事实证明他们没有。当他们试图修复它时，OpenSSL 引入了一个更严重的漏洞。Google 的 Adam Langley 可能是世界上最好的 TLS 实施者，他选择不在 Go 标准库的 TLS 实施中实施修复，并建议人们不要支持 CBC 密码套件，如果他们担心的话。
正确实施 TLS CBC 密码套件太难了。
随着攻击变种的改进，被认为完全修补和安全的实现被发现是不安全的。
人们知道肯定有比上面列出的问题更多的问题，因为历史告诉我们，每当一个人想到一个糟糕的 TLS 实现者可能会做错的新愚蠢事情时（比如重复随机数或只检查 MAC 的单个字节）并写入一个可以大规模检查这种错误的扫描仪，他们不可避免地会发现一些确实做错了但设法在生产中部署的实现，通常是在财富 500 强公司。
这篇尚未发表的论文讲述了最新一轮的一些情况：https ://github.com/RUB-NDS/TLS-Padding-Oracles
没有人知道较小的参与者（例如 cavium、citrix、F5、wolfSSL 和 mbedTLS）实施 TLS 的资格，可以说您可以依靠他们正确地执行此操作。存在一种性能更高且更容易正确实现的替代方案，因此正确的做法是放弃支持。
没有猜测，“为什么”总是很难回答。就密码学而言，我们对未来的最佳指导是过去的攻击。在这种特殊情况下，仅仅存在有缺陷的 CBC 实现就会导致 POODLE 攻击。
我们现在可能认为每个人都知道他们应该测试他们的填充字节方案，但这只是一个假设。可悲的是，太多的人在得到他们期望的好结果后就停止了测试，而没有确保他们的剩菜没有副作用。
现在，考虑实施 TLS 1.3 的成本。编写代码很容易。但是开发人员随后将不得不测试版本、算法、密钥交换等的组合噩梦。而且我们知道攻击者经常通过以意想不到的和新颖的方式组合元素来利用协议。他们可以从套件中扔掉的任何东西都可以使研究和测试它的数量级变得更简单。
CBC 真的应该受到责备，还是它只是导致意外错误导致漏洞？答案是，如果这是一条我们不需要的路径，也许最好完全关闭它，从而减少攻击面。