RFC 6176

RFC 6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 🎀

okay bestie, let's get into it 💅 This is RFC 6176, published by the IETF in March 2011 as a Standards Track document (ISSN 2070-1721). It was written by Sean Turner (IECA) and Tim Polk (NIST). It updates RFC 2246, RFC 4346, and RFC 5246. It doesn't list anything it obsoletes 🙈 Basically, it's a glow-up for the TLS backward compatibility rules ✨

Abstract

This doc says that when TLS clients and servers set up a connection, they never negotiate SSL version 2.0 🚫 It also updates the backward compatibility sections of TLS. Iconic, honestly 🦋

Status of This Memo

This is an Internet Standards Track document 🌸

This is an IETF product. It reflects what the IETF community agreed on 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚

You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6176 🍓

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they're in effect on the publication date. Read these carefully, because they spell out your rights and restrictions for this document 📜 If you pull Code Components out of this document, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚖️

1. Introduction ✨

A lot of IETF protocols lean on Transport Layer Security (TLS) [TLS1.0][TLS1.1][TLS1.2] for security. Love that for them 🥰 But some TLS clients and servers can also negotiate SSL version 2.0 [SSL2], and that version just doesn't offer enough security 💀 SSL version 2.0 has known deficiencies, which this doc walks through. It also requires that TLS clients and servers never negotiate SSL version 2.0 🛑

RFC 4346 [TLS1.1] and then RFC 5246 [TLS1.2] both warned implementers that the "ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste". This doc finally follows through on that by updating the backward compatibility sections of TLS [TLS1.0][TLS1.1][TLS1.2] 👑

1.1. Requirements Terminology 🧚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖

2. SSL 2.0 Deficiencies 💔

SSL version 2.0 [SSL2] has these deficiencies:

• Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151] 🙃
• Handshake messages aren't protected. That lets a man-in-the-middle trick the client into picking a weaker cipher suite than it would normally choose 😤
• Message integrity and message encryption use the same key. That's a problem if the client and server negotiate a weak encryption algorithm 🔑
• Sessions can be terminated really easily. A man-in-the-middle can slide in a TCP FIN to close the session, and the peer can't tell whether it was a legit end of the session 👻

3. Changes to TLS 🛠️

Because of the deficiencies in the previous section:

• TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO message format. Clients MUST NOT send any ClientHello message that specifies a protocol version less than { 0x03, 0x00 }. As all the earlier versions of TLS already said, the client SHOULD specify the highest protocol version it supports 🫢
• TLS servers MAY continue to accept ClientHello messages in the version 2 CLIENT-HELLO format, as specified in RFC 5246 [TLS1.2], Appendix E.2. This doesn't contradict the ban on actually negotiating SSL 2.0, so we're good 👍
• TLS servers MUST NOT reply with an SSL 2.0 SERVER-HELLO with a protocol version less than { 0x03, 0x00 }. Instead, they MUST abort the connection. So if the highest protocol version the client offers is { 0x02, 0x00 }, the TLS connection gets refused 🚪

Heads up: the number of servers supporting that "MAY accept" option is going down. Also, the SSL 2.0 CLIENT-HELLO rules out TLS protocol enhancements that need TLS extensions, because TLS extensions can only be sent as part of an (Extended) ClientHello handshake message ⚠️

4. Security Considerations 🔐

Literally this whole document is about security considerations 😭💅

5. Acknowledgements 🫶

The idea for this doc came from discussions between Peter Saint Andre, Simon Josefsson, and others on the Extensible Messaging and Presence Protocol (XMPP) mailing list 💬

Big thanks as well to Michael D'Errico, Paul Hoffman, Nikos Mavrogiannopoulos, Tom Petch, Yngve Pettersen, Marsh Ray, Martin Rex, Yaron Sheffer, and Glen Zorn for their reviews and comments 🌈

6. References 📚

6.1. Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[TLS1.0]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

[TLS1.1]    Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[TLS1.2]    Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.2", RFC 5246, August 2008.

6.2. Informative References

[MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

[SSL2]      Hickman, Kipp, "The SSL Protocol", Netscape
               Communications Corp., Feb 9, 1995.

[RFC6151]   Turner, S. and L. Chen, "Updated Security Considerations
               for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
               RFC 6151, March 2011.

Authors' Addresses 💌

Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA

EMail: turners@ieca.com

Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
USA

EMail: tim.polk@nist.gov

---

that's the whole tea, bestie 🌈✨ SSL 2.0 is out and we're not going back 💅👑