在CloudFlare，我们致力于确保加密的web对每个人都可用，即使是那些使用旧浏览器的人。同时，我们要确保尽可能多的人使用最现代、最安全的加密技术。改进大多数人使用的加密技术需要构建web浏览器和API客户端的组织与那些使用CloudFlare等web服务的组织之间进行协调。密码学是双向的。即使我们为客户支持最安全的加密算法，web访问者也不会从中获益，除非他们的web客户端支持相同的算法。我们继续探索密码块的密码链模式的历史。我们将解释为什么CBC被证明难以安全使用，以及最近web客户端采用安全密码的趋势如何帮助减少web对该技术的依赖。从CloudFlare自己的数据来看，支持更安全密码模式（如AEAD）的web客户端的百分比在六个月内从不足50%上升到70%以上，这对于互联网来说是个好兆头。什么是分组密码？密码通常分为两类：流密码和分组密码。流密码对数据进行逐位加密。明文和密文的长度总是相同的。纯流密码的例子是RC4和ChaCha20。虽然RC4不再被认为是安全的，但是我们仍然可以依赖ChaCha20作为一种安全的流密码在web上使用，但是它只是最近才被IETF标准化，因此没有被广泛采用。与流密码不同，流密码可以加密任何大小的数据，块密码只能加密固定大小的"块"中的数据。分组密码的例子有DES（8字节块）和AES（16字节块）。要使用块密码加密长度小于一个块的数据，您有几个选项。您可以将块密码转换为流密码（使用称为计数器模式的方法，稍后将详细介绍），也可以包含额外的字节作为填充，以将数据与块大小对齐。如果数据长度超过一个块，则需要将数据拆分为多个单独加密的块。这种分裂的过程是事情变得棘手的地方。加密大于块大小的数据的天真方法称为电子码本（ECB）模式。在ECB模式下，将数据分成与密码块大小匹配的块，然后用相同的密钥加密每个块。ECB被证明是加密大多数类型数据的一种非常糟糕的方法：如果加密的数据有冗余部分，比如一幅图像有许多相同颜色的像素，那么最后就会出现"Tux"问题（如下所示）。如果两个块具有相同的值，它们将被加密为相同的值。此属性允许攻击者通过查看密文块来知道哪些明文块匹配。例如，以下是Linux的"Tux"的高分辨率版本在ECB模式下加密时的外观：图片来自Filippo Valsorda的博客相同的明文块被加密为相同的密文块，这一事实给加密数据提供了一种不需要的结构，从而揭示了有关明文的信息。解决这一问题的一种方法是通过获取一个加密的输出并将其混合到下一个块的输入中，从而将块"链"在一起。有几种分组密码模式，但最初在SSL中被标准化的（并继续在TLS中使用）是密码块链接（CBC）。在CBC中，使用异或运算（XOR）将一个块的明文与前一个块的密文相结合。第一个块用随机生成的初始化向量（IV）进行异或运算。解密的工作原理是将前一个密文块（或IV）异变到解密的输出中。CBC有一些很好的特性。分组密码产生的密文是加密的，所以（希望）看起来是随机的。在CBC中，您将这些随机的加密数据混合到明文中，使得输出中不太可能有模式。另一个优点是解密可以并行进行，以加快速度。然而，在HTTPS和web环境中使用CBC已经被证明是比预期更多的麻烦。在TLS中如何加密记录TLS通过密码提供加密，通过消息认证码（MAC）提供完整性。当SSL最初被设计时，一个悬而未决的问题是：我们应该验证明文数据，还是应该先加密然后再验证加密的数据？这有时被称为MAC-then-encrypt或encrypt-then-MAC？他们选择了MAC然后加密（加密经过验证的数据），这已经被证明是不太理想的选择。在密码协议设计中，未经验证的字节可能会导致意外的弱点（这被称为密码末日原则）。当使用块密码模式（如CBC）加密数据时，需要用额外的字节填充最后一个块，以使数据与块大小一致。在TLS中，这个填充在MAC之后。（有一个TLS扩展，如rfc7366中所述，可以启用encrypt then MAC，但很少实现。）TLS记录具有以下格式。每个序列号都有一个8字节的序列号，该序列号存储在每个新序列号上并递增。请求的加密部分需要加起来达到16字节的倍数，但是为了本文的目的，我们假设这个长度是64字节（4个块）。在TLS中，有效的填充看起来像一个数字前面加上它自身的副本数。如果重复0次，那么如果数字为0x02，则重复0x02次：要解码一个块，解密整个消息，查看最后一个字节，删除它，然后删除那许多字节的填充。这将为您提供HMAC的位置。要计算MAC，取序列号、5字节头和消息，然后使用共享完整性密钥对它们进行HMAC。填充甲骨文这种结构的问题是它容易受到一种称为padding oracle攻击的技术的影响。2002年，Serge Vaudenay首次报道了针对TLS的攻击。填充甲骨文是攻击者修改发送到服务器的密文以提取明文值的一种方法。攻击者不必是ISP或政府，就可以进入请求的中间。如果他们和受害者在同一个本地网络上，他们可以使用一种称为ARP欺骗的技术。通过诱使受害者的机器将数据转发到攻击者的机器而不是路由器，他们可以读取、修改和测量从浏览器发送到服务器的每一条加密消息所需的时间。通过将JavaScript注入客户正在访问的未加密网站，他们可以让浏览器反复向目标HTTPS站点发送请求。这些请求包含有价值的数据，如登录cookies和CSRF令牌。如果TLS服务器在解密具有正确填充的密文和不正确填充的密文时的行为不同，攻击者就可以精心设计密文，这些密文提供足够的信息来显示明文数据。这听起来像是魔术，但实际上不是。给定密文，*解密数据*有三种可能的查看方式：无效的填充有效填充，错误的HMAC有效填充，正确的HMAC最初，TLS服务器将为情况1和2返回不同的错误代码。利用CBC的结构，攻击者可以构造256个密文，其最后一个字节解密为0x00到0xFF。通过查看错误代码，攻击者可以判断哪些密文被解密为值0x00，这是一个有效的0字节填充。有了这些知识，攻击者就可以构造256个猜测，其中最后一个字节是0x01，倒数第二个字节覆盖0-255。错误代码让攻击者知道哪一个解密为0x01，导致最后两个字节为0x01 0x01，这是另一个有效的填充。这个过程可以继续解密整个消息。填充是未经验证的，而且攻击者可以分辨正确和错误猜测的区别，这使得这种攻击非常强大。每次解密时，此错误代码都会向攻击者提供有关明文的少量信息。这就是所谓的旁道，第三方可以看到的信息泄露。通过返回案例1和案例2的相同错误代码，原始的杂耍攻击得到了缓解；然而，使用另一个旁道：定时，攻击再次恢复。请考虑在以下每种情况下，服务器必须执行的工作量：读取填充字节无效有效填充，错误的HMAC–读取填充字节，计算HMAC有效的填充，正确的HMAC–读取填充字节，计算HMAC在Vaudenay最初的攻击中，错误代码泄露了场景1和场景2之间的差异。在padding oracle的定时版本中，攻击者测量服务器响应所需的时间。快速响应意味着场景1，慢响应意味着场景2或3。定时攻击会受到一些抖动的影响，这是因为计算机很复杂，有时请求只需要比其他计算机更长的时间。但是，如果尝试了足够的次数，您可以使用统计信息来确定您所处的情况。一旦攻击者有了这个预言，就可以使用与上面描述的原始杂耍攻击相同的步骤来解密完整的明文。为了修复定时攻击，TLS实现被更改为即使填充无效也执行HMAC。现在，每当在解密密文中发现无效填充时，服务器都会假定填充为零，并对所有数据执行一个虚拟的HMAC。对于情况1、2和3，花费的时间应该是恒定的。或者我们是这么想的。走运事实证明，很难找到一个启发式方法，它需要一个分支程序，并使所有分支花费相同的时间。2013年，Nadhem AlFardan和Kenny Paterson发现TLS中仍然存在时间预言，基于HMAC采用不同的a