Google在他们的线上安全blog中声明他们将在近期取消对过时的SSL 3.0协议的支持。有一篇文章对相关漏洞CVE-2014-3566进行了详细的描述（在本文撰写时CVE数据还处于保密状态）。这个漏洞可以通过禁用SSL 3.0或直接禁用其中的CBC（密码块链）支持来解决。

这个问题源于TLS的向后兼容，它允许在会话无法完成时在较低的层次进行再次协商。当客户端和服务器均支持TLS协议的当前版本（本文撰写时是1.2），通信错误会导致客户端和服务器在较低一层进行再次协商。TLS 1.0是SSL的后继者（初是二十年前在Netscape Navigator中实现的）。TLS 1.0的实现允许回退到SSL 3.0，而SSL 3.0支持的一些加密方式存在被攻破的可能。TLS的新版本中禁用了一些加密算法 —— 例如八年前的TLS 1.1取消了一些可能被攻击的CBC算法，而在下一个规范中TLS 1.3取消了对所有CBC和RC4算法的支持。

这个攻击发生在两个部分。首先，通过包注入，在连接建立阶段，客户端和服务器的连接可能被中间人攻击重置，这将会导致客户端和服务器被强制在较低密级（例如SSL 3.0）进行再次协商。一旦攻击完成，论文中所描述的POODLE攻击（译者注：参考这里）导致秘钥的特定部分在会话过程中泄露。SSL 3.0使用RC4流加密（存在已知漏洞）或CBC模式的块加密。现在后者的安全性存疑。由于这是SSL提供的仅有的两种加密模式，所以应该避免使用SSL。这种攻击向服务器发送多256个数据包，这些包仅有块的后一个字节不同，通过这些数据包来分析加密块的后一个字节。在这些请求中，服务器只接受后一个字节正确的那个包，除此以外所有的数据包都被拒绝，这样就泄露了传输信息的一个字节。然后攻击者可以将整个序列移动一个字节（例如在请求路径末位增加一个字符），进而推导出负载中任意数量的字节内容，这有可能会导致本该被SSL保护的cookie值泄露。

对于无法简单禁用SSL 3.0的系统，TLS提供了一个选项TLS_FALLBACK_SCSV，可以在连接时禁止自动降级。客户端便可以确定他是否需要继续并且以一个较低密级连接，而不是将其作为TLS握手中的一个自动环节。

这个讨论与开发中的HTTP/2相关，这个协议目前正处于后确认阶段。问题612描述了对存在争议的9.2.2章进行的修改，增加了对于HTTP/2中可以使用的加密算法的限制，在更早的草案中，该章在TLS之上添加了一个额外的协商过程来确定加密算法是否合法。即使所选定的底层TLS连接版本对于客户端和服务端都已经可以接受，这一章同样特别要求在默认情况下禁用基于CBC模式进行连接。上周，对连接前256个字节的信息泄露可能性的关注似乎导致Google公布了这样的决定，即便HTTP/2本身不打算对TLS库进行额外限制，Google也会取消支持SSL 3.0以保护其线上环境。

尽管已经有了进展，但是依然有问题困扰着工作组，包括Roy Fielding称一个内嵌了安全需求的应用层协议是疯狂的，并且高调声明不会支持9.2.2，Jetty的作者（Greg Wilkins）声称不可能以一种有前瞻性的方式进行实现，Apple的Michael Sweet说9.2.2可能无法在约9亿的iOS和OSX设备上实现，微软也对提案投了反对票。

通过移除SSL 3.0和过时且存在漏洞的CBC模式，Google希望保障浏览器—服务器连接（已经使用了一段时间TLS 1.2）的安全，同时减轻连接被攻击后可能存在的进一步攻击。这有可能会消除HTTP/2规范的障碍，使其依赖TLS 1.2或以上版本，下个月将发布的TLS 1.3版本规范（同样禁用了CBC模式）有可能足以让HTTP/2前进。否则我们只能有以下结论：

据我所知，9.2.2提议的修改，要求服务器基于黑名单而非白名单工作，是不脆弱的。

只要客户端还使用白名单，服务器还基于黑名单并且服务器可以影响加密算法选择

并且它会禁用任何你提供的符合那3种模式加密算法

并且加密算法名称始终与那些模式不同

并且只要没有配置更多的模式。

我想你定义了脆弱。

查看英文原文： Google to remove support for SSL 3.0