第一個是基于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。