第一個是基于CBC的加密方式，塊加密的第一個block，C0 = E(Key, IV ⊕ M0)，C0是密文，Key是密鑰，IV是初始化向量，M0是明文。之后的block，Ci = E(Key, Ci-1 ⊕ Mi)，前面的加密會影響后面的加密，形成連鎖反應(yīng)。這種設(shè)計本來是為了加強安全，解決同明文同密文的問題的，結(jié)果反而帶來一些問題，前不久的Padding Oracle Attack也和這個有關(guān)。

第二個原因是HTTP是多請求的，一個SSL通道內(nèi)有多次HTTP通信。而SSL v3和TLS1.0設(shè)計的時候，將多個請求當成一個數(shù)據(jù)流來分塊加密，多次請求中的IV和KEY都維持不變。

假設(shè)已知block i中包含敏感信息M，同時假設(shè)下一個block的初始化向量X。那么，攻擊者用定制的P代換掉M，在這個包含敏感信息的block加密發(fā)送后插入一個明文 為X ⊕ Ci-1 ⊕ P的block，由CBC加密公式可知插入的明文加密后為E(Key, X ⊕ X ⊕ Ci-1 ⊕ P)即E(Key,  Ci-1 ⊕ P)。同時，正確的明文加密后為E(Key,  Ci-1 ⊕ M)。如果正常提交的那個數(shù)據(jù)包密文和插入的那個數(shù)據(jù)包密文一致，那么可知P等于M，也就是說你猜對了那個敏感信息。看來，只要知道X就可以猜解敏感信息 了，但是這個X不知道啊。不過仔細想想，X真的不知道么？基于CBC的鏈式結(jié)構(gòu)，它就是來自于上一個包的密文啊，于是攻擊者可以通過注入數(shù)據(jù)而暴力猜解 SSL加密通道中的某些數(shù)據(jù)了。

不過如果是很長的數(shù)據(jù)，暴力出來可能性不大，但是搞SQL注入的知道，剛興起注入的時候就是用left之類的函數(shù)一個字接一個字節(jié)的猜，很明確的知道最多需要猜解多少次。在BEAST攻擊中，如果恰當?shù)臉?gòu)造數(shù)據(jù)分組，那么也可以一個字接一個字節(jié)的猜解敏感信息了。

BEAST攻擊細節(jié)在>>http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html。

 

文章后面是利用WebSockets和java applet來做攻擊，就不看了，不擅長。攻擊難度比較大，不過解決方法很簡單，在服務(wù)端做設(shè)置，強制每傳輸了多少字節(jié)或者多少時間就變更一次KEY。