谷歌公布放弃 RC4 和 SSLv3 的详细计划
RC4 SSL SSLv3 https
![谷歌公布放弃 RC4 和 SSLv3 的详细计划](/data/attachment/album/201509/24/221300ntorc3jjzscoorxo.jpg)


不出所料，这周谷歌正式宣布准备放弃支持流算法 RC4 和 SSLv3 协议，这二者都有悠久的被攻击历史。


该公司的一名安全工程师亚当.兰利周四在一篇博客中宣布了该计划。虽然没有一个具体的时间表，但是兰利坚称，谷歌会在适当的时段内在其所有的前端服务器、Chrome、Android、爬虫和 SMTP 服务器中放弃使用 RC4 和 SSLv3。


事实上，该公司宣布放弃 RC4 和 SSLv3 并不令人惊讶，<ruby> 国际互联网工程任务组 <rp>  （ </rp> <rt>  IETF </rt> <rp>  ） </rp></ruby>在今年夏天发布的一个<ruby> 互联网标准跟踪文档 <rp>  （ </rp> <rt>  Internet Standards Track document </rt> <rp>  ） </rp></ruby>中[宣称了 SSLv3 的死亡](https://threatpost.com/ietf-officially-deprecates-sslv3/113503/)，说它“不够安全”，而且说“任何版本的 TLS 都比 SSLv3 安全”。


如兰利在博客中说到的，RC4 已经用了28年了，虽然其在早期的表现很好，但是多年来它一直是多种攻击的目标，其中一些攻击可以导致 [TLS 会话降级](https://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions-031413/77628/)和 cookie 解密。


作为这次计划的一部分，谷歌宣布了一些 TLS 客户端应该具有的最低安全性标准：


1. 必须支持 TLS 1.2
2. 在握手时必须包含<ruby> 服务器名字指示 <rp>  （ </rp> <rt>  SNI （server name indication） </rt> <rp>  ） </rp></ruby>扩展，还要包含将要连接的域名
3. 必须支持带有 P-256 和未压缩点的加密套件 TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256
4. 至少要信任 <https://pki.google.com/roots.pem> 中的证书
5. 证书操作一定能支持 DNS <ruby> 主题替代名称 <rp>  （ </rp> <rt>  SAN（Subject Alternative Name） </rt> <rp>  ） </rp></ruby>，并且这些主题替代名称可以包含一个通配符作为名字最左边的标签


兰利说：不满足需求的设备不会很快就停止工作，但是会受到 TLS 变化的影响，这可能持续到2020年。


“如果你的 TLS 客户端、web 服务器或者邮件服务器使用 SSLv3 或 RC4，虽然几年前就该更新了，不过现在更新总比不更新好。然而要注意，你现在使用 RC4 并不意味着你的客户端或网站就无法工作，TLS 会协商加密算法，但是如果你只支持 RC4 那就要出问题了。”，兰利说。


兰利在[这个月早些时候](https://threatpost.com/google-mozilla-microsoft-to-sever-rc4-support-in-early-2016/114498/)发到 [security@chromium.org](mailto:security@chromium.org) 邮件列表的一封帖子中宣布了废弃 RC4 的大致计划。确认这个算法会在将来的 Chrome 构建中禁用，可能会在 2016 年一、二月稳定。该公司也已经做了一些废弃 SSLv3 的工作：[随着取消 Chrome 中的 SSLv3 降级支持，](https://threatpost.com/google-removes-sslv3-fallback-support-from-chrome/109455/) POODLE 攻击就会失效，该公司也会逐步[淘汰 SHA-1 算法](https://threatpost.com/google-sunsetting-weak-sha-1-crypto-algorithm/108145/)。


OK
As expected, Google formally announced its intent to move away from the stream cipher RC4 and the SSLv3 protocol this week, citing a long history of weaknesses in both.

Adam Langley, a security engineer for the company, announced the plans through a blog post on Thursday. While there isn’t a concrete timeline, Langely insisted that Google is looking to do away with support for RC4 and SSLv3 in all of its frontend servers, Chrome, Android, webcrawlers, and SMTP servers, in the medium term.

The fact that the company is looking cut ties with both mediums shouldn’t come as little surprise.

The Internet Engineering Task Force [condemned SSLv3](https://threatpost.com/ietf-officially-deprecates-sslv3/113503/) in an Internet Standards Track document over the summer, calling it “not sufficiently secure,” adding that “any version of TLS is more secure than SSLv3.”

As Langely notes in the blog, RC4 is 28 years old, and while it fared well in the early goings, it’s been the target of multiple attacks over the years, including some that can lead to TLS [session compromise](https://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions-031413/77628/) and cookie decryption.

As part of the switch Google also announced a collection of minimum standards for TLS clients going forward. According to the post, Google will eventually require the following of devices:

- TLS 1.2 must be supported.
- A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that’s being connected to.
- The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
- At least the certificates in https://pki.google.com/roots.pem must be trusted.
- Certificate handling must be able to support DNS Subject Alternative Names and those SANs may include a single wildcard as the left-most label in the name.

Langley notes that devices that don’t meet the requirements won’t stop working anytime soon, but acknowledges they may be affected by TLS changes later down the line, up to the year 2020.

“If your TLS client, webserver or email server requires the use of SSLv3 or RC4 then the time to update was some years ago, but better late than never. However, note that just because you might be using RC4 today doesn’t mean that your client or website will stop working: TLS can negotiate cipher suites and problems will only occur if you don’t support anything but RC4,” Langley wrote.

Langely announced cursory plans to deprecate RC4 [earlier this month](https://threatpost.com/google-mozilla-microsoft-to-sever-rc4-support-in-early-2016/114498/) in a post to the security@chromium.org mailing list, confirming that the cipher would be disabled in a future Chrome build, likely stable around January or February 2016.

The company has already taken one step towards nixing SSLv3: a month after last fall’s POODLE attack [it did away with support for the fallback to SSLv3 in Chrome](https://threatpost.com/google-removes-sslv3-fallback-support-from-chrome/109455/), a move that went hand in hand with the company’s [phasing out of the SHA-1](https://threatpost.com/google-sunsetting-weak-sha-1-crypto-algorithm/108145/) cryptographic hash algorithm.