POODLE攻擊是針對SSLv3中CBC模式加密算法的一種padding oracle攻擊。這個攻擊方式和之前的BEAST攻擊方式很像，可以讓攻擊者獲取SSL通信中的部分信息的明文，比如cookie。和BEAST不同的是，它不需要對明文內容的完全控制，所以操作起來更加貼近實戰。
從根本上說，這是SSL設計上的問題，就像 Lucky13 和 這些漏洞里面描述的一樣，SSL的加密和認證過程搞反了，SSL先進行認證之后再加密。
首先考慮這個明文HTTP請求, 我把它分成了 8字節的塊，就像3DES加密，但是這個方法對16字節的AES塊加密一樣適用:
最后一個塊里包含了7個字節的填充(padding),用·來表示，最后一個字節7是填充長度，我用了虛構的8字節MAC校驗碼。在傳輸前，這些數據都會被3DES或者AES加密。現在來回顧下CBC解密的過程，這張圖來自wikipedia:
攻擊者可以控制HTTP請求中的路徑和主體，從而讓請求的內容滿足如下條件:
后面的padding填充部分填充了一整個block
cookie的第一個字節正好在某個塊的末尾的字節
攻擊者需要做的是把包含cookie第一個字節(出現在這個塊的末尾，例如塊中的內容是 Cookie:a，a正好在8字節塊的末尾)的那個塊,替換padding的那個塊發送給接收者(服務器)。
一般來說，服務器會拒絕這段密文，因為CBC校驗失敗了，攻擊者需要重新發送，平均來說，每256個請求中有一個會被服務器接受，只要服務器接受了，根據CBC的解密過程，攻擊者就知道了cookie的第一個字節(明文)的和上一個塊最后一個字節的密文 XOR 后是 7或者15(分別對應塊長度8或16)。
作為中間人，我們可以看到任何一段密文，所以
P XOR K = C
C XOR K = P
三個變量我們只要知道了兩個就可以解密出另一個，所以 Cookie第一字節 XOR 密文最后一個字節 = 15
我們只要把 15 XOR 密文最后一個字節就知道了cookie的第一個字節。
因為可以解密的窗口大小只有1字節(前面任意一個塊的最后一個字節)，所以需要通過js控制HTTP請求路徑的長度，比如 GET/, GET /A, GET /AA...把需要解密的cookie的位置逐漸頂到解密窗口中，每次解密一個字節平均需要256次請求，攻擊者就可以用256*n次構造的請求來解密SSLv3中任意位置的明文。
這個漏洞的主要成因是因為SSLv3沒有規定padding填充塊字節的內容，只校驗填充塊最后一個字節，因為TLS會檢查填充塊的內容所以在TLS上同樣的攻擊方式成功率只有2^-64或者2^-128。
把SSLv3關了，SSLv3已經過期用了15年了。
參考： https://www.imperialviolet.org/2014/10/14/poodle.html https://www.openssl.org/~bodo/ssl-poodle.pdf