0x00 背景
POODLE攻击是针对SSLv3中CBC模式加密算法的一种padding oracle攻击。这个攻击方式和之前的BEAST攻击方式很像，可以让攻击者获取SSL通信中的部分信息的明文，比如cookie。和BEAST不同的是，它不需要对明文内容的完全控制，所以操作起来更加贴近实战。
从根本上说，这是SSL设计上的问题，就像 Lucky13 和 Vaudenay's two atacks 这些漏洞里面描述的一样，SSL的加密和认证过程搞反了，SSL先进行认证之后再加密。
0x01 细节
首先考虑这个明文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。
0x02 解决方式
把SSLv3关了，SSLv3已经过期用了15年了。
参考： https://www.imperialviolet.org/2014/10/14/poodle.html https://www.openssl.org/~bodo/ssl-poodle.pdf
好博客
不错哦
路过 留名
密文被修改后，MAC很难校验通过，难道服务器只检查最好一个padding字节的长度？我觉得必须MAC必须正确服务器才接受，所以不明白256次是什么意思。不太明白原文An attacker can run Javascript in any origin in a browser and cause the browser to make requests (with cookies) to any other origin. If the attacker does this block duplication trick they have a 1-in-256 chance that the receiver won't reject the record and close the connection. If the receiver accepts the record then the attacker knows that the decryption of the cookie block that they duplicated, XORed with the ciphertext of the previous block, equals seven. Thus they've found the last byte of the cookie using (on average) 256 requests.
攻击者当然知道密文，攻击者知道每个block的密文，因为他是中间人，可以看到和修改密文。但是修改后的密文能否成功通过MAC的校验就是个问题了。 Padding正好在MAC后面，所以用MAC前面的密文替换padding，但是只有当解密出来的cookie和被被我们替换的padding的密文字节XOR出来正好是7或者15的时候，才会被认为是一个合法的padding block,因为前面的MAC也正好填满一个block。
Heart Bleed刚过去，Poodle又来了，没有所谓安全的东西
我觉得好像不是这样子的吧？按照原文的说法，攻击者是知道padding block前面的那个密文（也就是需要和该padding block做XOR操作的IV）的，因为这个是攻击者可以控制的：
When the receiver decrypts the last block it XORs in the contents of the previous ciphertext (which the attacker knows) and checks the authenticity of the data.
所以256应该是指我们对cookie的某个字节从0x00-0xFF进行选择吧？
哦，对，是我想错了，谢谢指点：）
16字节的block也是一样的，需要碰上的还是一个字节所以还是256
哦，多谢，IV是一个很重要的影响因子。1/256我也想明白了，一个字节是8位，总共有2的8次方种可能，出现7的可能就是1/256，不过要是15的话，应该是2的16次方分之一的概率吧……
这个我觉得是因为每次的IV都不一样，所以每次加密后密文的块都是不一样的，然而要解密的cookie的字符是一致的(如果cookie前的HTTP头没有变的话)，因为你不能控制IV，所以你不能控制和cookie字符XOR的那个密文字节，那个密文字节相当于就是随机的0x00-0xFF,所以需要正好那个密文字节和cookie字节 XOR后等于15或者7的时候，服务器才会认为解密正确完成。
1/256的概率其实就是0x00-0xFF的随机值正好能和cookie XOR 成7或者15……
这么快就发了分析文章，赞下！
我认为严格的说，这个不应该叫中间人攻击，攻击者并没有伪造身份介入会话，应该算窃听吧。
另外还有一个疑问，cookie前面的一个字的内容是固定的“TP/1.1\r\n”，那么是不是需要用js在合法用户的客户端不停构造这个字之前的内容，才有可能在padding中遇到7？不然每次padding的内容都是一样的哈，不会出现256种可能。
求解答。
还是比较苛刻的说啊
总的说来，利用这个漏洞需要你能控制js发送请求，并且解密通信中的一个字符平均需要256次请求
看着好复杂的说 T_T