背景介绍
2014年10月15日,Google发布了一份关于SSLv3漏洞的分析报告,报告中指出“该漏洞贯穿于所有的SSLv3版本中,利用该漏洞,黑客可以通过中间人攻击等类似的方式(只要劫持到的数据加密两端均使用SSL3.0),便可以成功获取到传输数据(例如cookies)
Google给出的官方建议:”关闭客户端SSLv3支持或者服务器SSLv3支持或者两者全部关闭。
东软网络安全攻防实验室对此问题进行了进一步的分析,该漏洞是在SSL 3.0的条件下利用了CBC的一个特性完成的,将从SSL 3.0的强制利用以及对CBC的恶意利用两个方面进行介绍:

SSL 3.0的强制利用
SSL 3.0是一个作废的不安全的协议,已经被后来的TLS 1.0,TLS 1.1和TLS1.2所取代。攻击者控制客户端和服务器的交互,使得握手尝试总是失败,通信协议每次失败就会降低一个版本。比如最开始协商利用TLS1.2,失败后协商利用TLS 1.1,又失败协商利用TLS 1.0,再次失败后,最后利用SSL来通信。通过这种方法,强制用户和服务器利用SSL 3.0。

CBC的恶意利用
前提1:此漏洞最简单的利用方式:加密的流中最后一个整块(block)的内容全部是来自填充字符加密后的结果。并且这个填充字符满足下列条件:前L-1个字节的内容是任意的(L表示每个块包含的字节数),而最后一个字节的值为L-1;
前提2:解密公式为Pi=Dk(Ci)Ci-1
前提3:密文流的最后一个块(block)完全是填充(padding)得来的。攻击者将此块用相同密文流中此块之前的加密块替代,如果Dk(Ci)⊕Cn-1=L-1,那么密文流仍然能够被成功地解密。

举例:
假设每个块是由16个字节构成的,分别为C[0]…C[15],并且假设cookies的大小是已知的。MAC的大小在SSL 3.0中的长度是固定大小即20个字节,因此一个POST请求将会是如下格式:
POST /path Cookie:name=value…\r\n\r\nbody || 20-byte MAC ||padding
攻击者会同时控制request path的长度和request body的长度,使得下面两个条件能够成立:
1.     密文流的最后一个块完全是填充字节加密后的结果;
2.     Cookies的第一个未知的字节(也就是攻击者待解密的内容)调整到前一个加密块的最后一个字节位置。(也就是说cookies的其余部分在紧接着的加密块当中)。
攻击者利用2中的块替代1的块,将重组后的密文流发送给服务器端。(备注:原版资料里讲可能直接提交会被服务器拒绝,但是重复提交,最多256次就会被接受)服务器端接受以后,根据前提3可知Dk(Ci)[15]⊕Cn-1[15]=15,因此就会有Pi[15]=15⊕Cn-1[15]⊕Ci-1[15](根据前提2可知),到这一步,攻击者还原出了cookies的第一个字节,攻击者可以接着调整,将cookies的第二个字节挪到这个位置,根据上面的方式解密出cookies的第二个字节,循环这个过程,直至将cookies的内容全部得到。

解决方案
客户端或服务器端需要停用 SSL v3,或者停用 SSL v3中的 CBC加密方法。

参考文档
https://www.imperialviolet.org/2014/10/14/poodle.html
https://www.openssl.org/~bodo/ssl-poodle.pdf