最近，Guido Vranken开发了一种针对 TLS 流密码的新型攻击，称为Bicycle，并在此Websense 的博客文章中引用。
它基于流密码的特性，即明文长度和密文长度之间存在 1:1 的关系（尽管它们可能不相同），从而允许攻击者关联请求中的一些已知数据并发现长度字段（例如密码长度）。如果你知道用户有一个 8 字符的密码，你会从暴力破解中减少很多工作，想出一个字典，几个小时后就能让你进入。
完整的解释在上面链接的第一篇博客文章中托管的PDF中，供那些想了解它的真正工作原理的人使用。
基本上它会影响所有流密码，特别是伽罗瓦计数器模式 (GCM)，主要与 TLS 1.2 一起使用，作为 AEAD 密码套件的一部分。快速搜索其他 AEAD 密码表明它们也是流密码，因此也容易受到此问题的影响。还是他们不都受到影响？
所以问题是，可以使用哪种密码？分组密码不受这个特定问题的影响，但它们中的大多数都有自己的问题，这使得这是一个“挑选你的毒药”而不是带来解药的问题。这里有没有人知道可以与 TLS 1.2 一起使用的已知密码（由 NIST 推荐），并且不会将其自身的缺陷带入方程式？
文章的PDF开头是：
通常假设封装在 TLS 中的 HTTP 流量不会显示其部分的确切大小
这不是我会说的。相反，假设它通常由不了解的人假设。TLS是加密，加密擅长隐藏数据内容，而不是数据长度。这并不完全是新奇的。然而，TLS“隐藏一切”的想法确实仍然很普遍（这是错误的，一直都是，但教育很慢，尤其是当人们不想接受教育时）。
一些人认为，基于 CBC 的密码套件意味着一个填充，它可能以某种方式隐藏加密数据长度的细节，因为长度被填充为块大小的倍数。这种“隐藏效应”在实践中并不真正成立，因此更明智的做法是假设没有密码套件可以帮助您隐藏正在发送的数据的长度。
如果你真的想隐藏用户密码的长度，那么你必须正确地做到这一点，让发送者在发送之前将其填充到固定长度（这可以在几行 Javascript 中完成）。但是，考虑到长度仍然会在很多地方泄漏；众所周知，长度会影响客户端和服务器的处理时间，并且可以检测到这一点（至少，在实验室条件下证明了这种侧信道泄漏）。此外，当用户输入他的密码时，听筒内的任何攻击者都可以简单地计算敲击次数并获得相同的信息（实际上，通过用他的智能手机记录噪音并稍后低速播放——攻击者甚至可能获得关于实际的字母，因为它们在典型的键盘中会发出明显的声音）。
一个现实的答案是指出，如果泄露密码长度允许破坏它，那么这是一个糟糕的密码，你应该修复它。长度只是问题的一小部分，即错误的密码是错误的。