RFC7568：Deprecating Secure Sockets Layer Version 3.0，June 2015
梗概
RFC 6101 中指定的安全套接字层版本3.0 (SSLv3) 不够安全。本文档要求不使用 SSLv3。作为替代版本，推荐使用传输层安全 (TLS) 1.2 (RFC 5246)，它是更加安全和功能强大的协议。
本文档更新了 RFC 5246 及其前身的向后兼容性部分，以禁止回退到 SSLv3。
本备忘录的状态
这是一个 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。
有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7568。
版权声明
版权所有 (c) 2015 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 简介
自 1996 年发布以来，SSLv3 协议 [RFC6101] 一直受到一系列攻击，无论是其密钥交换机制还是其支持的加密方案。尽管在 1999 年被 TLS 1.0 [RFC2246] 取代，随后在 2002 年被 TLS 1.1 [RFC4346] 和 2006 年 1.2 [RFC5246] 取代，但这些替代版本的可用性尚未普及。因此，许多 TLS 实现都允许协商 SSLv3。
SSLv3 的前身 SSLv2 不再被认为足够安全 [RFC6176]。现在遵循 SSLv3。
2、 术语
本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119] 中的描述进行解释。
3、 不要使用 SSLv3.0
不得使用 SSLv3。不得允许从任何版本的 TLS 协商 SSLv3。
任何版本的 TLS 都比 SSLv3 更安全，但最好使用可用的最高版本。
实际上，客户端不得发送 ClientHello.client_version 设置为 {03,00} 的 ClientHello。同样，服务器不得发送 ServerHello.server_version 设置为 {03,00} 的 ServerHello。收到协议版本设置为 {03,00} 的 Hello 消息的任何一方都必须以“protocol_version”警报消息进行响应并关闭连接。
从历史上看，TLS 规范并不清楚在发送 ClientHello 时记录层版本号 (TLSPlaintext.version) 可以包含什么。[RFC5246] 的附录 E 指出可以选择 TLSPlaintext.version 来最大化互操作性，尽管没有确定的值是理想的。该指南仍然适用；因此，TLS 服务器必须接受任何值 {03,XX}（包括 {03,00}）作为 ClientHello 的记录层版本号，但它们不得协商 SSLv3。
4、 SSLv3全面破解
4.1、 记录层
SSLv3 的密码区块链 (Cipher Block Chaining，CBC) 结构中使用的非确定性填充允许恢复明文 [POODLE]。或者说，SSLv3 的 CBC 模式使用有缺陷的 MAC-then-encrypt 结构，该结构随后在 TLS 版本 [RFC7366] 中被替换。不幸的是，纠正此缺陷的机制依赖于扩展（TLS 1.0 中添加的一项功能）。无法以相同的方式更新 SSLv3 以纠正此缺陷。
SSLv3 中 CBC 模式的缺陷由它定义的流密码的弱点反映出来。在定义的那些中，目前只有 RC4 被广泛使用。然而，RC4 表现出严重的偏见，也不再适合使用 [RFC7465]。
这使得 SSLv3 没有合适的记录保护机制。
4.2、 密钥交换
当使用重新协商 [RFC5746] 或会话恢复 [TRIPLE-HS] 时，SSLv3 密钥交换容易受到中间人攻击。每个缺陷都通过扩展在 TLS 中得到了修复。同样，无法更新 SSLv3 来纠正这些缺陷。
4.3、 自定义加密原文
SSLv3 定义了伪随机函数(PRF)、散列消息身份验证代码 (Hashed Message Authentication Code，HMAC) 和数字签名原文的自定义构造。此类结构缺乏 TLS 使用的标准结构所接受的深入加密审查。此外，所有 SSLv3 原文都依赖于SHA-1 [RFC3174] 和 MD5 [RFC1321]：这些散列算法被认为是弱的，并且正在被更强大的散列函数系统地取代，例如 SHA-256 [FIPS180-4]。
5、 能力有限
SSLv3 无法利用添加到最新 TLS 版本的许多功能。这包括 SSLv3 不支持的 ClientHello 扩展启用的功能。
尽管 SSLv3 可以从新的密码套件中受益，但它不能从新的加密模式和功能中受益。其中，以下几点尤为突出：
*在[RFC5246]中添加了带有附加数据的认证加密（AEAD）模式。
*椭圆曲线Diffie-Hellman (Elliptic Curve Diffie-Hellman，ECDH) 和椭圆曲线数字签名算法 (Elliptic Curve Digital Signature Algorithm，ECDSA) 在 [RFC4492] 中添加。
*无状态会话票证 [RFC5077]。
*数据包操作模式DTLS [RFC6347]。
*应用层协议协商[RFC7301]。
6、 安全考虑
整个文档旨在通过禁止使用不安全的协议来提高安全性。
7、 参考文献
7.1、 规范参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, . [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, . [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, . [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, .
7.2. 参考资料
[FIPS180-4] U.S. National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-4, March 2012. [POODLE] Moeller, B., "This POODLE bites: exploiting the SSL 3.0 fallback", October 2014, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, . [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, . [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, 2014
