我正在阅读这篇文章，其中讨论了一种针对 TLS 的新攻击，称为幸运十三。它声称允许对 HTTPS 连接进行可重复的中间人攻击。
它被描述为实际执行是相当不切实际的：
- 每次调整尝试都会导致 TLS 会话终止，这可能既明显又耗时。
- 每个经过调整的会话都需要在相同的数据包位置具有相同的明文，以便彻底完成调整。
- 作者需要对 216 次详尽的调整进行 27 次重复（即 800 万次无效的 TLS 会话！），以产生足够的具有统计意义的时序数据以获得可靠的结果。
但似乎还有其他声音认为它可能成为一种实用的、可重复的对 HTTPS 的攻击。
我想知道：
最重要的是：
当攻击在 2003 年首次被描述时（通过时序分析的“坏填充”预言机），预期的攻击场景是一个电子邮件客户端（例如 Outlook Express），它定期（例如每分钟一次）连接到服务器以了解是否有一些新的邮件已到达（使用POP协议时无法通知您有新邮件；您必须轮询）。由于每个连接都以相同的身份验证阶段开始，因此目标密码在流中处于确定性、可重现的位置，并且由于 Outlook Express 在错误报告方面出了名的差（即它要么是静默的，要么只是更新一个长期存在的用户被训练忽略的错误弹出窗口），那么这是一个很好的攻击设置。
需要指出的重要一点是，此类攻击必须发生在解密点附近，即“有趣的数据”（密码）即将被解密的地方。在邮件服务器场景中，这是在服务器附近，而不是客户端。
“幸运十三”新增两个数据点：
它指出，针对定时攻击的常见防御（即，当填充错误时，表现得好像它很好并仍然计算 MAC）可能会泄漏一点（因为“假定填充”没有确切的长度“良好的填充”）。2003 年的初始攻击使用大约 1 毫秒的延迟，而新的泄漏大约短了一千倍，大约 1 微秒。
它表明，在实验室条件下（100 Mbit/s 以太网，目标和攻击者之间只有一个开关，数百万个措施），低至约 1 微秒的测量是可行的。
第一点当然很有趣。然而，我认为第二点存在这个根本缺陷：如果攻击者能够如此接近目标，那么他可以通过许多其他方式获胜。事实上，定时攻击是通过基于时间的数据泄漏从封闭系统中提取信息。我们密码学家倾向于专注于密码层，因为这是我们的工作，而密码学就是集中秘密：“密钥”是保密的本质，是一个非常有价值的目标。但是，加密的重点是保护敏感数据，任何对机密数据的处理都可能通过时间泄露其中的一部分。
在完整的数据处理堆栈中，SSL/TLS 层位于底层 TCP/IP 堆栈和以各种方式使用机密数据的“应用程序”之间。由于解密发生在 TLS 中，因此 TCP/IP 层只能看到加密的块，因此没有什么可以泄漏的。但是，如果认为泄漏可能只发生在 TLS 层中，那就太乐观了，近乎荒谬。完整的应用程序代码可能同样容易受到定时攻击。虽然对 TLS 本身的攻击更具新闻价值，但我声称对应用程序代码的攻击更有可能是毁灭性的。
综上所述，“幸运十三”攻击很有趣，但不太现实。关于定时攻击，TLS 层只是冰山一角。再进一步滥用这个比喻，担心“幸运十三”有点像担心泰坦尼克号上的腐蚀：从抽象的角度来看，这是一个有效的担忧，但不像其他与划船有关的问题那么紧迫。
我向您指出 Matthew Green 的这篇特别博客文章，它很好地描述了这次攻击。特别是这句话。
但这不可能在 TLS 上起作用！它会杀死会话！请回想一下，我将其描述为对数据报 TLS (DTLS) 的实际攻击——以及对 TLS 本身的更具理论性的攻击。*这是有原因的。
原因是 TLS（而不是 DTLS）还包括一个我还没有提到的对策：只要记录无法解密（由于 MAC 错误或填充错误），TLS 服务器就会终止会话。DTLS 不这样做，这使得这种攻击边界实用。（尽管它仍然需要数百万个数据包查询才能执行。）
标准 TLS 的“会话终止”功能似乎可以停止填充预言机攻击，因为它们需要攻击者进行许多次解密尝试。终止会话将攻击者限制为一次解密——直觉上这似乎是它的结束。
但实际上，事实证明并非如此。
你看，关于填充预言机攻击的一个巧妙的事情是它们可以跨不同的会话（密钥）工作，前提是（a）你的受害者愿意在会话断开后重新启动会话，并且（b）秘密明文出现在每个流中的相同位置。幸运的是，浏览器和 HTTPS 的设计让我们满足了这两个要求。要使目标浏览器启动许多连接，您可以为其提供一些自定义 Javascript，使其重复连接到 SSL 服务器（如在 CRIME 攻击中）。请注意，Javascript 不需要来自目标网络服务器——它甚至可以在不相关的非 HTTPS 页面上提供服务，可能在不同的选项卡中运行。简而言之：这是非常可行的。Morover，由于 HTTP(S) 协议的设计，这些连接中的每一个都将在 HTTP 流中的已知位置包含 cookie。虽然您可能无法解密流的其余部分，但这些 cookie 值通常是您破解某人帐户所需的全部内容。因此，这种 cookie 攻击的唯一实际限制是服务器重新启动所有这些连接所需的时间。TLS 握手并不快，而且这种攻击每字节可能需要数万（或数百万！）个连接。所以在实践中，TLS 攻击可能需要几天时间。换句话说：不要惊慌。因此，这种 cookie 攻击的唯一实际限制是服务器重新启动所有这些连接所需的时间。TLS 握手并不快，而且这种攻击每字节可能需要数万（或数百万！）个连接。所以在实践中，TLS 攻击可能需要几天时间。换句话说：不要惊慌。因此，这种 cookie 攻击的唯一实际限制是服务器重新启动所有这些连接所需的时间。TLS 握手并不快，而且这种攻击每字节可能需要数万（或数百万！）个连接。所以在实践中，TLS 攻击可能需要几天时间。换句话说：不要惊慌。
另一方面，也不要自满。作者提出了一些巧妙的优化，可以在不久的将来将 TLS 攻击带入可行的领域（对于 TLS）。
你问：
从实验室环境到已知 LAN 或从已知 LAN 到 WAN 有多困难？
由于攻击涉及测量非常小的时序差异，因此在实验室环境之外利用它可能会有些困难。
鉴于我不一定能控制软件，防御这种攻击有多困难和有多大必要？是否有随机填充和延迟 HTTPS 响应的方法以避免定时攻击？
最终用户似乎几乎无法防御这种攻击。系统管理员可以通过更新 SSL 实施、切换到 RC4 密码套件（作为临时措施）和使用 AEAD 密码套件（如 AES-GCM）来帮助缓解这种情况。
这如何与当前针对 SSL/TLS 的攻击（例如 BEAST）相互作用？它是否提供放大效果？
就像攻击背后的团队所建议的那样，可以通过将其与 BEAST 风格的技术相结合来增强攻击。
在考虑未来的实施时，这个结果有多重要？
从理论上讲，这种攻击实际上并不是什么新鲜事，众所周知，在应用 MAC 之前，您应该始终先加密。
至于防御，在 Linux 下可以做这样的事情：
tc qdisc 添加 dev eth0 root netem 延迟 3ms 1ms
如Kaminsky 的 2012 Black Ops 演示文稿中所述，为网络接口添加随机延迟作为对定时攻击的基本防御。
当然，那里有性能权衡，但在许多情况下，几毫秒是微不足道的。