Raccoon是TLS规范中的计时漏洞，会影响HTTPS和其他依赖SSL和TLS的服务。这些协议允许Internet上的每个人浏览Web、使用电子邮件、在线购物和发送即时消息，而无需第三方能够读取通信内容。
浣熊允许攻击者在一定条件下破解加密并读取敏感通信。该漏洞确实很难利用，并且依赖于非常精确的计时测量和可利用的特定服务器配置。
Diffie-Hellman(DH)密钥交换是在TLS连接中交换密钥的成熟方法。当使用Diffie-Hellman时，两个TLS对等体随机生成私钥(a和b)并计算它们的公钥：gamodp和gbmodp。这些公钥在TLS密钥交换消息中发送。一旦接收到两个密钥，客户端和服务器都可以计算共享密钥GABmodp-称为预主秘密-该密钥用于导出具有特定密钥导出函数的所有TLS会话密钥。
我们的浣熊攻击利用了TLS规范的侧通道；TLS 1.2(和所有以前的版本)规定在进一步的计算中使用前主密钥中的所有前导零字节都被剥离。由于所得到的预主秘密被用作密钥导出函数的输入，该密钥导出函数基于具有不同定时简档的散列函数，因此精确的定时测量可以使攻击者能够从TLS服务器构造预言机。此预言告诉攻击者计算的预主密码是否从零开始。例如，攻击者可以窃听客户端发送的Ga，将其重新发送到服务器，并确定结果预主密码是否从零开始。
从预主密码中了解一个字节对攻击者帮助不大。然而，在这里，攻击变得有趣起来。假设攻击者截获了包含值g a的ClientKeyExchange消息。攻击者现在可以构造与g a相关的值，并在不同的TLS握手中将它们发送到服务器。更具体地说，攻击者构造值gri*ga，其导致预主秘密gri*b*gab。根据服务器计时行为，攻击者可以找到导致预主密码从零开始的值。最后，这有助于攻击者构造一组方程，并使用隐数问题(HNP)的解算器来计算在客户端和服务器之间建立的原始预主密钥。
浣熊攻击：在TLS-DH(E)中查找和利用最高有效位的预言。罗伯特·梅杰、马库斯·布林克曼、尼姆罗德·阿维拉姆、朱拉伊·索莫罗夫斯基、约翰尼斯·米特曼和约尔格·施文克。
大概不会吧。浣熊是一种复杂的定时攻击，很难利用。要解密一个真实的TLS会话，需要很多明星对齐。然而，也有例外。在满足(极少数)情况下，raccoon允许攻击者解密用户和服务器之间的连接。这通常包括但不限于用户名和密码、信用卡号、电子邮件、即时消息和敏感文档。
该攻击通常以TLS 1.2及更低版本中的Diffie-Hellman密钥交换为目标。攻击有两个先决条件：服务器在TLS握手中重复使用公共DH密钥。如果服务器配置为使用静态TLS-DH密码套件，或者服务器使用临时密码套件(TLS-DHE)并将临时密钥重复用于多个连接，则会出现这种情况。幸运的是，这在攻击之前就已经被认为是不好的做法，因为它不提供前向保密性。
攻击者可以执行精确的计时测量，这允许他/她查明DH共享密钥的第一个字节是否从零开始。
这是一个很好的问题，可能没有令人满意的答案。加密(！)。据我们所知，针对TLS的攻击通常不会被现实世界的攻击者大量使用。攻击者需要特殊的环境才能使浣熊攻击起作用。他需要靠近目标服务器才能执行高精度定时测量。他需要受害者连接才能使用DH(E)，服务器才能重复使用临时密钥。最后，攻击者需要观察原始连接。对于一个真正的攻击者来说，这是一个很高的要求。然而，与攻击者破解现代密码原语(如AES)所需的操作相比，攻击看起来不再复杂。但尽管如此，现实世界中的攻击者可能会使用比此攻击更简单、更可靠的其他攻击载体。
可能是。您可以使用以下工具进行检查：www.ssllabs.com，如果"；DH public server param(Ys)reuse"；表示"；yes"；，则您的服务器可能易受攻击。
该漏洞不是真正的客户端漏洞。客户端对此无能为力，除了不支持DH(E)密码套件。现代浏览器应该不再支持这些密码套件。据我们所知，Firefox是最后一个支持DHE的主要浏览器，并于2020年6月在Firefox 78中放弃了对它的支持(到目前为止，大多数客户端应该至少运行该版本，如果不是更高版本的话)。您可以在此处检查您的浏览器是否仍然支持DH(E)，但重申一下，没有任何实际意义。
不需要，您必须针对要攻击的每个单独连接执行攻击。
不是的。在TLS1.3中，前导零字节为DHE密码套件(以及ECDHE密码套件)保留，密钥不应重复使用。但是，TLS 1.3存在一个变体，它显式地允许(甚至鼓励)密钥重用，称为ETS或eTLS。如果在任一变体中重用临时键，则它们可能导致微体系结构侧通道，这可能会被利用，尽管保留了前导零字节。我们建议不要使用这些变体。
一般不会。在TLS中，PMS的前导零字节保留在用于ECDH的所有版本的TLS中。因此，安全、无泄漏的实现应该是可能的。在其他协议中，情况可能并非如此。据我们所知，即使存在旁信道，目前最知名的算法仍然需要更多的已知比特才能用于ECDH，而不是浣熊可能获得的比特。我们仍然想指出的是，HNP的ECDH变体还没有像传统的HNP那样得到广泛的研究。因此，不能保证将来对这些算法的改进也可能使这些攻击对ECDH起作用。
遗憾的是没有。软件中的错误也可能使此攻击在没有计时测量的情况下成为可能。我们执行了大规模的Internet扫描来分析各种TLS服务器，并意外地发现几个设备由于预主密码的第一个字节表现出不同的行为。到目前为止，我们能够识别和报告其中之一：F5BIG-IP的旧版本。您可能应该检查您没有运行易受攻击的配置(请参阅CVE-2020-5929)，因为这允许在不进行复杂计时测量的情况下安装直接攻击。如果您正在运行易受攻击的配置，您可能现在就应该打补丁。请注意，此外，在易受攻击的F5 BIG-IP的情况下，只有在服务器重复使用DH公钥的情况下，攻击才是实用的。我们建议不要忽视攻击者测量精确计时的能力，而是要远离客户端的DHE，并避免对服务器重复使用密钥。
我们对互联网上排名前10万的Alexa网站进行了测量。3.33%的服务器至少重复使用一次短暂的DH密钥。Springall et al.截至2016年，Alexa前100万名中有4.4%的人重复使用了DH密钥。
该漏洞已有20多年未被发现(至少从1996年发布的SSLv3开始)。多亏了谷歌的大卫·本杰明(David Benjamin)指出了这个问题，TLS 1.3在草案14中修复了这个漏洞。
该攻击结合了所涉及的原语的许多细节。隐数问题(HNP)，我们最终使用它来利用定时侧信道，从来没有被用来利用它的原始目标(Diffie-Hellman密钥交换)。这是因为没有人知道如何获取Diffie-Hellman共享秘密中最重要的部分。从那时起，HNP主要用于其他设置，如DSA或ECDSA，而它也适用于DH的知识被遗忘了。TLS-DH(E)主控密钥中的前导零被剥离的事实也是TLS的一个细节，可能只有几个人知道。
我们在一个古老的布格兹拉词条中找到了这个问题的答案。看起来SSL3应该实现PKCS#3，它要求保留PMS的前导零位。但是实现者误解了SSL 3规范中的措辞：
执行常规的Diffie-Hellman计算。协商的密钥(Z)用作PRE_MASTER_SECR[...]。
取而代之的是，前导零字节被剥离。当这个被发现的时候，损害已经造成了。对于TLS1.0，随后有意将其更改为删除前导零字节，这可能是为了避免进一步混淆。当椭圆曲线后来被添加到标准中时，他们明确提到必须保留PMS的前导零，从而导致目前的情况，即为ECDH保留它们，而不是为DH保留它们。
浣熊不是首字母缩写。浣熊只是一种可爱的动物，早就应该以它们的名字命名袭击了：)。
F5指定问题CVE-2020-5929。特别值得一提的是，几个F5产品允许执行特殊版本的攻击，而不需要精确的计时测量。F5建议他们的客户修补产品或强制使用新鲜的临时密钥。请参阅F5安全建议。
OpenSSL指定问题CVE-2020-1968。OpenSSL从1.0.2f版开始默认使用新的DH密钥(使SSL_OP_SINGLE_DH_USE成为对CVE-2016-0701的默认响应)。因此，该攻击主要在使用DH证书时影响OpenSSL 1.0.2，这种情况很少见。OpenSSL 1.1.1从不重用DH密钥，也不实现任何静态DH密码套件。为了减轻攻击，开发人员将所有剩余的DH密码套件移到弱SSL密码列表中。此外，在本研究的推动下，开发人员还激活了OpenSSL 1.0.2w中新一代的EC临时密钥。请参阅OpenSSL安全建议。
莫兹拉分配了问题cve-2020-12413。这个问题已经通过禁用Firefox中的DH和DHE密码套件得到了解决(这在浣熊泄露之前就已经计划好了)。
BearSSL和BoringSSL不受影响，因为它们不支持DH(E)密码套件。GNUTLS、wolfSSL、Botan、mbed TLS和s2n不支持静态DH密码套件。他们的DHE密码套件从不重复使用临时密钥。
我以为TLS-DH(E)有安全证明(这里和这里)。为什么证据中没有包括这一点呢？
当前许多密码证明技术的一个问题是，它们通常不是为(协议内的)侧信道建模而设计的。他们将假设所有操作始终在固定时间内执行，尽管这在实践中可能不可能实现。此外，它们不对原语中的秘密编码进行建模。这些细节在经过验证的协议模型中会丢失。为了证明TLS-DH(E)是安全的，必须引入PRF-ODH假设，并且证明依赖于该假设对TLS成立。从理论上讲，这一假设对于TLS仍然适用，但对于所有实际方法，该假设在实际的TLS实现中并不成立。
你们中的许多人可能还记得布莱琴巴赫的攻击(另见机器人的实际功绩)。这种自适应选择密文攻击通过处理RSA PKCS#1 v1.5消息来利用服务器行为差异。它允许攻击者在几千次连接之后解密预主密码。从攻击者模型的角度来看，浣熊攻击与Bleichenbacher的攻击非常相似；攻击者还需要向服务器发送几条修改后的ClientKeyExchange消息，观察其响应，并执行一些密码计算来泄露预主密码。与Bleichenbacher的攻击不同，浣熊的目标是DH密钥交换。
幸运13是另一个很酷的攻击，当你阅读浣熊攻击的描述时，你可能会想到这一点。在Lucky 13中，AlFardan和Paterson利用了在不同TLS记录长度上计算的HMAC的不同计时行为。这使他们能够区分有效和无效的填充，并应用CBC填充Oracle攻击。该攻击在野兽攻击场景中工作，并允许攻击者解密TLS记录。相反，我们的浣熊攻击利用了在不同长度的主控秘密上进行HMAC计算所产生的计时行为差异。它会泄露预主密码，从而基于单个被窃听的ClientKeyExchange消息解密整个连接。我们的浣熊攻击灵感来自幸运13号副频道。
您可以想象到，使用DH密钥交换的协议有很多。例如，我们可以确认SSH也会删除前导零位。然而，根据Springall et.。与TLS相比，ALSSH在避免密钥重用方面做得更好，因此该攻击在SSH中不可利用。
JSON Web Encryption仅提供ECDH密钥协议。应按照NIST特别出版物800-56A中所述处理已建立的共享密钥。本文档建议保留前导零字节，见附录C.1和C.2。
还有许多其他使用DH密钥交换的协议。它们的分析通常很困难，因为文档不提供如何处理已建立的共享机密的信息，因此需要进行源代码分析或手动测试。同样有趣的是，类似的浣熊式攻击是否也适用于最新的后量子方案。
那么，保留DH共享密钥中的前导零字节的协议是否完全安全，不会受到这种攻击？
我们的主要攻击依赖于由去掉的零导致的TLS规范问题。对不同长度的预主秘密执行密钥导出函数会导致不同的定时行为。这是在我们的测量中表现良好的侧通道。
但是，即使共享密钥保留了前导零字节，也很可能会出现允许攻击者发动此类攻击的不同侧通道。实现恒定时间计算是非常具有挑战性的；旁信道可能来自底层的大数库实现或将共享秘密与模长对齐。虽然此类边信道不如本文中描述的边信道重要，但较强的攻击者仍然可以使用诸如微体系结构攻击等强大的技术来查明计算的共享秘密是否从零开始。
这个漏洞真的严重到值得给它起个名字、一个徽标和一个网页吗？
这是TLS规范中的一个漏洞，所以我们认为...是的。此外，创建它们非常有趣：)