Google近期取消对SSL 3.0协议的支持

更新时间:2014-10-29 09:58:04点击次数:613次

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

  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息