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

第二個原因是HTTP是多請求的，一個SSL通道內(nèi)有多次HTTP通信。而SSL v3和TLS1.0設(shè)計的時候，將多個請求當(dāng)成一個數(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的鏈?zhǔn)浇Y(jié)構(gòu)，它就是來自于上一個包的密文啊，于是攻擊者可以通過注入數(shù)據(jù)而暴力猜解 SSL加密通道中的某些數(shù)據(jù)了。

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