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

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

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

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

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

 

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