Google 停止对 SSL 3.0 的支持

阅读数:4054 2014 年 10 月 28 日

话题:GoogleDevOps语言 & 开发架构

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


感谢曹知渊对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。