我正在使用 Firefox 浏览器 28.0 版。为了访问https://www.yahoo.com,我在中间放置了一个带有自签名证书的代理,我的客户端 PC 可以访问 HTTPS 站点。然后,我在客户端 PC 中嗅探流量并观察到一件奇怪的事情;
从 Firefox 发送的每个 HTTPS 请求都被分成两个 TCP 段。一个只有一个字符长(“ G”),另一个包括其余字符(“ ET / HTTP 1.1...”)
为什么 Firefox 会有这样的行为?

我正在使用 Firefox 浏览器 28.0 版。为了访问https://www.yahoo.com,我在中间放置了一个带有自签名证书的代理,我的客户端 PC 可以访问 HTTPS 站点。然后,我在客户端 PC 中嗅探流量并观察到一件奇怪的事情;
从 Firefox 发送的每个 HTTPS 请求都被分成两个 TCP 段。一个只有一个字符长(“ G”),另一个包括其余字符(“ ET / HTTP 1.1...”)
为什么 Firefox 会有这样的行为?

这是已在 SSL 库中部署的“1/n-1 拆分”技术,作为 BEAST 攻击的解决方法。
BEAST 攻击是对选定明文攻击的 Web 上下文的应用。攻击在以下情况下有效:
在 SSL 3.0 和 TLS 1.0 中,一条记录的 IV 是前一条记录的最后一个加密块,因此攻击者可以通过窥探线路看到它(攻击设置假设攻击者可以窃听线路并将信息发送到在受害者的浏览器中植入了一些邪恶的 Javascript——这在“餐厅中的 WiFi”场景中是现实的,具有攻击者控制的接入点)。
“1/n-1 拆分”可以防止攻击,因为具有 1 个字节的帧包含一个 MAC 值,攻击者无法预测该值,并且该值也被加密。微妙之处在于时间问题:当攻击者选择要加密的数据时,“1”和“n-1”条记录都没有发出;只有当攻击者推送了他的 n 个字节时,才会计算并发送这两条记录。最终效果是攻击者在发送他的 n 个字节进行加密之前将无法知道 n-1 记录的 IV。攻击者仍然能够预测“1”记录的 IV,但一个字节不足以让攻击者发起 BEAST 攻击。
从理论上讲,“0/n 分割”是可能的(第一帧根本没有数据,然后是实际帧)并且会更好(以学术方式),但是,尽管它在标准上得到支持就空记录而言,许多已部署的实现会阻塞,因此“1/n-1 拆分”被认为更实用。
BEAST 攻击还要求攻击者对他需要发送的字节进行大量控制,例如,他不能仅限于 ASCII 字符;原型攻击依赖于两个已经修复的额外漏洞,因此即使没有 1/n-1 拆分,攻击也将不再有效。但是 SSL 库设计者很谨慎,不希望看到 SSL 安全性受到应用程序另一个组件中的漏洞的危害。
TLS 1.1 及更高版本不受此影响,因为它们的记录标头包含特定于记录的 IV。