RFC 7568

Title Block: RFC 7568 🎀

Okay bestie, let's get into RFC 7568! 💖 It's called Deprecating Secure Sockets Layer Version 3.0, and it's an IETF Standards Track doc from June 2015 (ISSN 2070-1721). The IETF put it out, and the authors are R. Barnes and M. Thomson from Mozilla, A. Pironti from INRIA, and A. Langley from Google. 🌈 It updates RFC 5246, which is the TLS 1.2 spec, and it doesn't say it obsoletes anything. Super clear 💅

Abstract ✨

SSLv3, the Secure Sockets Layer version 3.0 described in RFC 6101, is not sufficiently secure, and this doc says it must not be used 🙅‍♀️ The replacements, especially Transport Layer Security (TLS) 1.2 (RFC 5246), are way more secure and capable protocols, so there's no reason to stick with SSLv3 🦋

This doc updates the backward compatibility section of RFC 5246 and its predecessors so that falling back to SSLv3 is prohibited. Bye bye, fallback 👋

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got 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 🌸

Want the current status, any errata, or a way to send feedback? Head over to http://www.rfc-editor.org/info/rfc7568 ✨

Copyright Notice 🔐

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these documents carefully, because they lay out your rights and restrictions for this doc 🧾 If you extract Code Components from this document, they must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Do Not Use SSL Version 3.0  . . . . . . . . . . . . . . . . .   3
4.  SSLv3 Is Comprehensively Broken . . . . . . . . . . . . . . .   3
  4.1.  Record Layer  . . . . . . . . . . . . . . . . . . . . . .   3
  4.2.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . .   4
  4.3.  Custom Cryptographic Primitives . . . . . . . . . . . . .   4
5.  Limited Capabilities  . . . . . . . . . . . . . . . . . . . .   4
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction 🌸

Since it came out in 1996, the SSLv3 protocol [RFC6101] has gotten hit with a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports 😭 It got replaced by TLS 1.0 [RFC2246] in 1999, then TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246]. But those replacement versions haven't been available everywhere, so lots of TLS implementations have ended up allowing SSLv3 to be negotiated 🙈

The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows 🦋

2. Terminology 🧚

Here's the key words list. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖

3. Do Not Use SSL Version 3.0 🚫

SSLv3 MUST NOT be used. Negotiating SSLv3 from any version of TLS MUST NOT be permitted. Absolutely not, no exceptions 💅

Any version of TLS is more secure than SSLv3, though the highest version available is preferable 👑

Pragmatically, clients MUST NOT send a ClientHello with ClientHello.client_version set to {03,00}. Similarly, servers MUST NOT send a ServerHello with ServerHello.server_version set to {03,00}. Any party that receives a Hello message with the protocol version set to {03,00} MUST respond with a "protocol_version" alert message and close the connection 🔥

Historically, TLS specs weren't clear about what the record layer version number (TLSPlaintext.version) could contain when sending ClientHello 🤷‍♀️ Appendix E of [RFC5246] notes that TLSPlaintext.version could be picked to maximize interoperability, though no definitive value is identified as ideal. That guidance still applies, so TLS servers MUST accept any value {03,XX} (including {03,00}) as the record layer version number for ClientHello, but they MUST NOT negotiate SSLv3. The vibe is: accept it, never negotiate it 🫶

4. SSLv3 Is Comprehensively Broken 💀

4.1. Record Layer 🍓

The non-deterministic padding used in the Cipher Block Chaining (CBC) construction of SSLv3 trivially permits the recovery of plaintext [POODLE]. Ngl, that's bad 😭 More generally, the CBC modes of SSLv3 use a flawed MAC-then-encrypt construction that has since been replaced in TLS versions [RFC7366]. Unfortunately, the fix for this flaw relies on extensions, which is a feature added in TLS 1.0. SSLv3 can't be updated to correct this flaw in the same way 🥲

The flaws in the CBC modes of SSLv3 are mirrored by the weakness of the stream ciphers it defines. Of those, only RC4 is currently in widespread use. RC4, however, shows serious biases and is also no longer fit for use [RFC7465]. Not it 🙅‍♀️

So, SSLv3 is left with no suitable record protection mechanism. Iconic behaviour from a protocol 💀

4.2. Key Exchange 🗝️

The SSLv3 key exchange is vulnerable to man-in-the-middle attacks when renegotiation [RFC5746] or session resumption [TRIPLE-HS] are used. Each flaw has been fixed in TLS by means of extensions. Again, SSLv3 can't be updated to correct these flaws 😩

4.3. Custom Cryptographic Primitives 🧪

SSLv3 defines custom constructions for Pseudorandom Function (PRF), Hashed Message Authentication Code (HMAC), and digital signature primitives. These constructions lack the deep cryptographic scrutiny that the standard constructions used by TLS have received. Furthermore, all SSLv3 primitives rely on SHA-1 [RFC3174] and MD5 [RFC1321]. These hash algorithms are considered weak and are being systematically replaced with stronger hash functions, such as SHA-256 [FIPS180-4] 🌈

7.2. Informative References 🦋

okay so the informative refs are the "good to know" stuff, not the must-reads 📚✨

[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, <http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html>. 💀 this is the one that started the whole POODLE drama, iykyk 🙈

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>. 🌸

[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, <http://www.rfc-editor.org/info/rfc3174>. 🧚

[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, <http://www.rfc-editor.org/info/rfc4492>. ✨

[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, <http://www.rfc-editor.org/info/rfc5077>. 🎀

[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, <http://www.rfc-editor.org/info/rfc5746>. 🫶

[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <http://www.rfc-editor.org/info/rfc6176>. 💅

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>. 🦋

[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, <http://www.rfc-editor.org/info/rfc7301>. 🌈

[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. 👑 the triple handshake paper, lowkey terrifying 😭

---

Authors' Addresses 💌

Richard Barnes Mozilla

EMail: rlb@ipv.sx

Martin Thomson Mozilla

EMail: martin.thomson@gmail.com

Alfredo Pironti INRIA

EMail: alfredo@pironti.eu

Adam Langley Google

EMail: agl@google.com