本文讲的是HTTP压缩仍让加密连接处于风险之中,安全研究人员近期改进了一项已有三年历史的攻击方法：
这种攻击类型被称为 BREACH ，是“利用超文本自适应压缩算法，进行浏览器侦查和信息窃取”（Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext）的简称。许多 Web 服务器使用 gzip 和 DEFLATE 算法来减少 HTTP 的响应延迟，然而，这两种加密算法会泄露关于加密连接的信息，使得中间人攻击成为可能。一旦中间人介入，就可以恢复认证 cookie 等敏感信息。
3年前美国举行的 Black Hat 大会上，安杰洛 普拉多（Angelo Prado）、尼尔 哈里斯（Neal Harris）、约尔 古拉克（Yoel Gluck） 这三位研究人员首次展示了这种攻击方式。从理论上讲， BREACH 攻击有可能影响所有 SSL 和 TLS 加密方案，但研究人员当时提出的方法对于利用 RC4 等数据流加密处理的连接最为有效。
来自雅典国家技术大学（National Technical University of Athens）的迪米特里 卡拉考斯塔和雅典大学（University of Athens）的狄奥西斯 乾罗斯（Dionysis Zindros）是另外一组研究人员。他们改进了 BREACH 攻击，让其更适用于攻击如今更加常用的 AES 等 TLS 分组密码。
卡拉考斯塔和乾罗斯在亚洲上周举行的 Black Hat 大会上展示了对 BREACH 技术的改进，并发布了一份名为 Rupture 的开源框架，可用于发动这类与加密相关的攻击。
他们展示了两种针对 Gmail 和 Facebook Chat 的概念验证攻击，以证明很多网站都存在这一漏洞，即使是那些最注重安全的也不例外。
BREACH 要求攻击者处于能够拦截受害者 Web 流量的网络位置上。做到这一点的方式有不少：连接到同一无线网络、入侵路由器，或者从网络架构的更高位置来发动攻击，比如通信运营商和美国国安局。
不过，攻击者还需要找到存在漏洞的应用，它们能够接受 URL 参数，并将输入反射到加密响应消息中去。
比如研究人员演示的 Gmail 入侵： Gmail 的移动网页版支持输入反射，响应页面上包含通过 URL 参数传递的搜索字符串，比如有些信息会显示没有搜索到特定字符串。此外，如果请求来自经过认证的合法会话，响应中还会带有标明本次会话的认证令牌。
gzip 压缩在 HTTP 中的工作方式是这样：如果在响应中有同一个字符串的多个实例，第一个实例将被保留，而其余实例将被替换成指向第一个实例位置的短引用，以减少响应消息的体积。
因此，对于 Gmail 而言，如果用户搜索的刚好是认证令牌完全一致的字符串，哪怕是它的一部分，在响应消息中也将相同字符序列的两个实例。由于压缩的存在，响应将比使用其它字符串进行搜索时的体积更小。
就像在 Gmail 攻击过程中显示的那样，攻击者使用 BREACH 技术的目标如下：诱使用户的浏览器向存在漏洞的应用发送大量请求信息，猜测认证令牌的内容。响应中的认证令牌可能受到加密保护，但每当搜索字符串与认证令牌的一部分契合时，攻击者观察到的响应消息都会比正常情况要小一点。
通过将新确认的字符添加到已有结果中，持续改变新请求中的搜索字符串，最终将获得认证令牌中的每个字符。这种方法将每次 HTTP 压缩的结果作为确认标识，实际上是针对各个字符的暴力破解攻击。
Rupture 框架可以帮助攻击者在用户浏览器打开的每个 HTTP 连接中注入恶意代码。这段代码可以强制浏览器向后台存在漏洞的 HTTPS 应用发出请求。分组密码和数据流加密有所不同，它会在每个响应中加入噪声：在加密过程之前添加被称为“填充”（Padding）的冗余比特，让响应可以被分割成相等大小的区块。要想利用 BREACH 技术过滤掉噪声，恢复加密数据，需要比应对数据流加密方式时多得多的请求次数才能做到。
乍看起来，这让 BREACH 攻击更难实现了。然而，卡拉考斯塔和乾罗斯设计了一种基于统计学的方法，通过计算请求同一个字符时多组响应的平均长度，过滤掉噪声。两位研究人员还进行了其它改进，并引入了搜索引擎平行化技术，大大提升了攻击使用分组密码的 TLS 的效率。
研究人员在发布的技术论文中写道， BREACH 攻击技术发布三年之后， RC4 已被公认为不安全的，如今大多数站点使用 AES 分组密码。“脸书等一些服务也整合了防止 BREACH 攻击的机制。然而， BREACH 的基本攻击机制仍旧有效，而包括脸书在内的大多数流行站点依旧支持存在漏洞的端点。”
研究人员总结称：“我们的研究证明，通过改进 BREACH ，能够攻击主流 Web 应用。这也同时说明， TLS 流量在实务层面上仍可以被视为不安全的。”
最近提出的一项互联网标准被称为第一方/同站点 cookie ，它可以保护站点免遭 BREACH 攻击。如果浏览器也采取该机制，可以防止来自其它站点的请求响应信息中包含 cookie 。
也就是说，如果 A 站点的代码指示浏览器向 B 站点发起请求， 即使浏览器已经和 B 站点之间有了活动的、经认证的会话，该请求也不会包含用户面向 B 站点的认证 cookie 。设计这一机制的初衷是防止跨站请求伪造（Cross-site Request Forgery，CSRF）攻击，但由于 BREACH 也采取了与 CSRF 类似的方式来发起恶意跨站请求，该机制对后者也将有效。
谷歌 Chrome 在版本号51中将启用对同站点 cookie 的支持，该版本将在今年五月发布稳定版。然而，如果还有许多浏览器并未采取该机制，网站管理者将很难产生对 cookie 添加“同站点”标识的动力。