图片：@0xabad1dea解释的"僵局"昨天，来自INRIA、微软研究院、约翰·霍普金斯大学、密歇根大学和宾夕法尼亚大学的一个小组发表了一篇深入分析用于TLS和其他协议的Diffie-Hellman算法。这个分析包括一个针对TLS协议本身的新的降级攻击，称为Logjam，它利用了导出密码（就像FREAK一样）。首先，让我首先说，CloudFlare客户没有受到影响，也从未受到影响。我们不支持客户端或源端的非EC Diffie-Hellman密码套件。我们也不会用20英尺长的棍子碰出口级密码。但为什么CloudFlare客户是安全的，Logjam又是如何工作的呢？Diffie Hellman和TLS这是一个关于DH如何工作以及如何在TLS中使用DH的详细技术介绍如果您已经知道这一点并想了解攻击，请跳到下面的"Enter export crypto，Enter Logjam"。相反，如果您对螺母和螺栓不感兴趣，并且想知道谁处于风险中，请跳到"那么，受到影响的是什么？"要启动TLS连接，双方客户机（浏览器）和服务器（CloudFlare）需要安全地就密钥达成一致。这个过程被称为密钥交换，它发生在TLS握手过程中：在传输加密数据之前发生的消息交换。在NickSullivan之前的博客文章的第一部分，有一个关于TLS握手的详细描述。在下面，我将只讨论理解当前攻击所需的想法。有许多类型的密钥交换：静态RSA、Diffie-Hellman（DHE密码套件）、椭圆曲线Diffie-Hellman（ECDHE密码套件）和一些不常用的方法。DHE和ECDHE密钥交换的一个重要特性是它们提供前向保密性。也就是说，即使服务器密钥在某个时刻被泄露，它也不能用来解密过去的连接。保护交换的信息不受未来突破的影响非常重要，我们很自豪地说，94%的CloudFlare连接都提供了这一点。本文的研究和此攻击适用于普通的非EC Diffie-Hellman密钥交换（DHE）。这就是它在高层次上的工作原理（别担心，我将在下面更详细地解释每个部分）：客户机在打开连接时公布对DHE密码套件的支持（在所谓的客户端Hello消息中）服务器选择参数并使用这些参数执行其一半的DH计算服务器签署参数，它的DH共享与它的长期证书，并将整个过程发送给客户端客户端检查签名，使用参数执行其一半的计算，并将结果发送到服务器这两个部分把所有的东西放在一起，并派生出一个共享的秘密，它们将使用这个密钥来保护连接（有关每一步的更深入分析，请参阅上面的Nick Sullivan的博客文章"短暂的Diffie-Hellman握手"部分。）让我们来解释一下刚才通过屏幕的一些术语。""客户端"是浏览器，"服务器"是网站（或CloudFlare为网站提供服务的边缘）。"参数"（或组）是一些大数字，用作DH计算的基础。它们可以，而且通常是固定的。最终秘密的安全性取决于这些参数的大小。这项研究认为512和768位是弱的，1024位是可以被像政府这样真正强大的攻击者破解的，2048位是一个安全的大小。证书包含一个公钥，是您（或您的CloudFlare）从CA为您的网站颁发的证书。客户端确保它是由它信任的CA颁发的，并且它对访问的网站有效。服务器使用相应的私钥对其在DH密钥交换中的份额进行加密签名，这样客户端就可以确保它与网站的真正所有者（而不是MitM）就连接密钥达成一致。最后，DH计算：在使用paint的Wikipedia上有一个很好的解释。tl；dr是：服务器选择一个秘密"a"然后，它使用一些参数作为基值进行计算——从中得到一个值"a"，并将其发送给客户端（而不是"a"！）客户机选择一个秘密"b"，从服务器获取参数，同样地，它计算一个发送到服务器的值"b"这两个部分将"a"+"B"或"B"+"a"组合在一起，从而得出一个共享的、相同的秘密——这是不可能从"a"+"B"中计算出来的，而"a"+"B"是唯一在网上传播的东西所有这些的安全性取决于参数的强度/大小。输入export crypto，输入Logjam到目前为止，还不错。Diffie-Hellman很好，它提供了前向保密性，如果参数足够大，它是安全的，并且参数是由服务器选择和签名的。有什么问题吗？输入"导出密码"！出口密码术是90年代美国对密码出口限制的产物。为了在美国不允许出口"强加密"的国家支持SSL，许多实现支持称为导出模式的弱化模式。我们已经看到了一个成功的攻击，因为连接可能会被迫使用这些模式，即使他们不想使用，这就是畸形漏洞所发生的情况。这表明，在这些模式变得无用20年后，我们仍在处理增加的复杂性的结果。它与Diffie-Hellman的工作原理是客户机请求DHE_导出密码套件，而不是相应的DHE导出密码套件。鉴于此，服务器（如果它支持DHE_EXPORT）为交换选择小的、可断开的512位参数，并进行常规的DHE密钥交换。服务器没有安全地向客户机发送信号，因为导出密码套件，它选择了这么小的DH参数。这是Logjam"降级攻击"的核心协议缺陷：MitM攻击者截获客户机连接并将所有接受的密码套件替换为DHE_EXPORT密码套件服务器选择弱的512位参数，执行其一半的计算，并用证书的私钥为参数签名。客户端Hello、客户端密码套件和所选密码套件都不是由服务器签名的！客户会认为服务器选择了DHE密钥交换，并且只是自愿地选择了小参数。从它的角度来看，它无法知道服务器是被MitM欺骗的！然后，攻击者将破坏两个弱DH共享中的一个，恢复连接密钥，并继续与客户端进行TLS连接不完美的前向保密：Diffie Hellman在实践中失败的程度-图2客户机没有其他方法来保护自己，除了在沙地上划清DHE参数的脆弱程度（例如至少1024位）并拒绝连接到希望选择较小参数的服务器之外。这是所有现代浏览器都在做的，但以前没有这样做过，因为它会导致中断，而且人们认为，如果服务器不正常，就无法诱使服务器选择如此弱的参数。服务器可以通过拒绝导出密码套件和从不签署小参数来保护自己。关于参数大小和重用但是对于DH参数来说，有多小太小了呢？本文对此也进行了深入的分析。首先要理解的是参数可以被重用，而且经常被重用。前100万个Alexa域中有17.9%使用相同的1024位参数。攻击者可以只使用参数执行大部分计算，然后在几分钟内中断使用这些参数的任何DH交换。因此，当许多站点（或VPN服务器等）共享相同的参数时，"断开"这些参数所需的时间投资就更有意义了，因为这样一来，攻击者就可以轻松地断开许多连接。研究小组对最常见的512位（导出）参数进行了预计算，以证明Logjam的影响，但他们表示担心，真正的、更强大的攻击者可能会对常见的普通dhe1024位参数做同样的操作。最后，在他们的互联网范围的扫描中，他们发现许多服务器甚至为非出口DHE提供易受攻击的512位参数，以便支持旧的TLS实现（例如，旧的Java版本）。那么，受影响的是什么？如果客户端/浏览器接受小的DHE参数作为任何连接的一部分，则会受到影响，因为它无法知道自己被诱骗到一个弱的导出级别连接中。在撰写本文时，大多数主流浏览器都存在漏洞，但正在将DH参数的大小限制为1024位。你可以查一下你的来访情况weakdh.org网站.如果服务器/网站支持DHE_EXPORT密码套件或使用DHE的小参数，则该服务器/网站易受攻击。您可以在中找到有关如何修复此问题的测试和说明https://weakdh.org/sysadmin.html。8.4%的Alexa Top百万HTTPS网站最初易受攻击（其中82%和10%使用相同的两个参数集，使得预计算更加可行）。CloudFlare服务器不接受DHE_EXPORT或DHE。我们提供ECDHE。一些有趣的相关统计数据：到CloudFlare客户站点的TLS连接中，94%使用ECDHE（更准确地说，其中90%是某种类型的ECDHE-RSA-AES，10%是ECDHE-RSA-CHACHA20-POLY1305），并提供了前向保密性。其余使用静态RSA（AES为5.5%，3DES为0.6%）。为了使攻击成功，客户端和服务器都需要易受攻击，因为服务器必须接受签名较小的DHE_导出参数，并且客户端必须接受它们作为有效的DHE参数。最后一点：这样的事件最终对安全行业和整个网络都是一件好事，因为它们意味着有技能的人正在寻找我们所依赖的东西来保护我们的连接并修复其缺陷。他们还把焦点放在支持低强度加密和旧设备的复杂性上，如何危及和增加我们所有安全工作的难度。如果你读过这里，觉得很有趣