解析beast攻击的两个本质原因

第一个是基于CBC的加密方式，块加密的第一个block，C0 = E(Key, IV ⊕ M0)，C0是密文，Key是密钥，IV是初始化向量，M0是明文。之后的block，Ci = E(Key, Ci-1 ⊕ Mi)，前面的加密会影响后面的加密，形成连锁反应。这种设计本来是为了加强安全，解决同明文同密文的问题的，结果反而带来一些问题，前不久的Padding Oracle Attack也和这个有关。

第二个原因是HTTP是多请求的，一个SSL通道内有多次HTTP通信。而SSL v3和TLS1.0设计的时候，将多个请求当成一个数据流来分块加密，多次请求中的IV和KEY都维持不变。

假设已知block i中包含敏感信息M，同时假设下一个block的初始化向量X。那么，攻击者用定制的P代换掉M，在这个包含敏感信息的block加密发送后插入一个明文 为X ⊕ Ci-1 ⊕ P的block，由CBC加密公式可知插入的明文加密后为E(Key, X ⊕ X ⊕ Ci-1 ⊕ P)即E(Key,  Ci-1 ⊕ P)。同时，正确的明文加密后为E(Key,  Ci-1 ⊕ M)。如果正常提交的那个数据包密文和插入的那个数据包密文一致，那么可知P等于M，也就是说你猜对了那个敏感信息。看来，只要知道X就可以猜解敏感信息 了，但是这个X不知道啊。不过仔细想想，X真的不知道么？基于CBC的链式结构，它就是来自于上一个包的密文啊，于是攻击者可以通过注入数据而暴力猜解 SSL加密通道中的某些数据了。

不过如果是很长的数据，暴力出来可能性不大，但是搞SQL注入的知道，刚兴起注入的时候就是用left之类的函数一个字接一个字节的猜，很明确的知道最多需要猜解多少次。在BEAST攻击中，如果恰当的构造数据分组，那么也可以一个字接一个字节的猜解敏感信息了。

BEAST攻击细节在>>http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html。

 

文章后面是利用WebSockets和java applet来做攻击，就不看了，不擅长。攻击难度比较大，不过解决方法很简单，在服务端做设置，强制每传输了多少字节或者多少时间就变更一次KEY。