Google停止对SSL 3.0的支持

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

　　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 种模式加密算法

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

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

我想你定义了脆弱。