Deprecating Secure Sockets Layer Version 3.0 (RFC 7568)

Internet Engineering Task Force (IETF) ^ | 06/2015 | R. Barnes et.al.

[zeugma]

A post for the computer techies on the site

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 7568                                    M. Thomson
Updates: 5246                                                    Mozilla
Category: Standards Track                                     A. Pironti
ISSN: 2070-1721                                                    INRIA
                                                              A. Langley
                                                                  Google
                                                               June 2015

Deprecating Secure Sockets Layer Version 3.0

Abstract

The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

1. Introduction

Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3.

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

2. Terminology

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. Negotiation of SSLv3 from any version of TLS MUST NOT be permitted.

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 receiving 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 specifications were not clear on what the record layer version number (TLSPlaintext.version) could contain when sending ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version could be selected to maximize interoperability, though no definitive value is identified as ideal. That guidance is still applicable; therefore, 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.

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]. More generally, the CBC modes of SSLv3 use a flawed MAC- then-encrypt construction that has subsequently been replaced in TLS versions [RFC7366]. Unfortunately, the mechanism to correct this flaw relies on extensions: a feature added in TLS 1.0. SSLv3 cannot be updated to correct this flaw in the same way.

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

This leaves SSLv3 with no suitable record protection mechanism.

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 cannot 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. Such constructions lack the deep cryptographic scrutiny that 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].

5. Limited Capabilities

SSLv3 is unable to take advantage of the many features that have been added to recent TLS versions. This includes the features that are enabled by ClientHello extensions, which SSLv3 does not support.

Though SSLv3 can benefit from new cipher suites, it cannot benefit from new cryptographic modes and features. Of these, the following are particularly prominent:

• Authenticated Encryption with Additional Data (AEAD) modes are added in [RFC5246].

• Elliptic Curve Diffie-Hellman (ECDH) and Digital Signature Algorithm (ECDSA) are added in [RFC4492].

• Stateless session tickets [RFC5077].

• A datagram mode of operation, DTLS [RFC6347].

• Application-layer protocol negotiation [RFC7301].

6. Security Considerations

This entire document aims to improve security by prohibiting the use of a protocol that is not secure.

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

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

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

[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>.

7.2. Informative References

[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>.

[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.

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

[zeugma]

This is pretty big actually for those of us who support various devices across large organizations. They are basically saying that all SSL encryption mechanisms are fundamentally broken, and cannot be fixed. These protocols need to be disabled in favor of TLS. Modern browsers will handle TLS just fine. Eventually, the use of SSL v1/v2/v3 is going to need to be completely abandoned because of how broken and ultimately insecure they are. This is going to cause a lot of problems, because you're going to have lots of network appliances and similar things that will not support the TLS protocol from a server standpoint to access their administrative interfaces. As these appliances age, eventually you'll likely get to the point where you have to keep older, (and thus unpatched) browers around to even connect to these devices to administer them.

None of this is going to happen immediately. Things just don't work that fast for this type of thing. However, it's something that folks are going to want to keep in mind when looking at infrastructure deployments going forward. If the hardware doesn't support TLS, you'll need to be asking "why not?"

I must admit that in general I concur with their reasoning. The vulnerabilities in SSL they point out do exist, and are not fixable because of the RFCs that define the protocol. Perhaps a fix could be made, but then that would break backwards compatibility. Anyway, TLS is the successor to the SSL protocol in any case. (You can think of it as SSL V4, but that name wasn't used due to trademark issues)

Why does this matter?

Well, if you want to have secure credit card transactions on the internet. You shouldn't be using SSL. It's been long known that V1 and V2 implementations were broken from a security perspective. I knew there were attacks on V3, but hadn't really looked into them in the past. I have to agree with the author of this RFC. "Do Not Use SSL Version 3.0"

[ClearCase_guy]

SSLv3 Is Comprehensively Broken

Seems like most of the important stuff in the world is in the same boat.

[zeugma]

I figure this might be apropos for all 3 tech lists (though I’d bet there’s a lot of overlap between them)

[zeugma]

Seems like most of the important stuff in the world is in the same boat.

Come to think of it you're right.

Congress Is Comprehensively Broken

The Supreme Court Is Comprehensively Broken

The Presidency Is Comprehensively Broken

The Justice Department Is Comprehensively Broken

Yeah. you're right. It fits everywhere

[tophat9000]

Thank for posting..im a network engineer in security so

down side actually fixing it will be more work..

but the up side...its more work

[dayglored]

> I figure this might be apropos for all 3 tech lists (though I’d bet there’s a lot of overlap between them)

Overlap be damned, this is critically important to any professionals from any of our lists.

Windows ping coming up...

[dayglored]

SSL v3 is broken beyond repair - do not use ... PING!

You can find all the Windows Ping list threads with FR search: search on keyword "windowspinglist".

This thread is mainly for the techies and sysadmins and other professionals, but every computer user should at least be aware of this.

[zeugma]

Thanks. It’s a brand new rfc and is pretty much advisory, but I hadn’t really had a feel for how broken ssl v3 was. I have to wonder if ssh has the same issues with the protocols. I’ll be looking around a bit for info on that tomorrow.

[Myrddin]

My project went through some digestive upset when Firefox disabled SSLv3. The weblogic server needed tweaking. Some apps using the libcurl compiled into a C++ program needed servicing as well. I'm still advocating for signed certs on client and server sides. It always comes down to money. Purchasing certs. Installing. Configuring for mandatory use.

[Myrddin]

In many cases it just amounts to editing a configuration file and set a list of acceptable protocols. The server side is pretty easy. The client side can be painful in proportion to the number of users you support.

[Swordmaker]

I agree with Zeugma and DayGloRed, SSL V3 is broken and we should not be using it. . . However, until the mail servers get their collective heads out of their posteriors to change it to a better security, there is not much the average user can do except scream at the system administrators, as it is better than using nothing. For you mail Server administrators, and mail client programmers, get us something better! — PING!

Apple Security Ping!

If you want on or off the Mac Ping List, Freepmail me.

[tophat9000]

Well I work for a company that does PCI compliance... Network segmentation, firewall installation, architecture....bottom line its going to be a lot of boxes to touch

[ProtectOurFreedom]

Would they could all be deprecated as simply as drafting an RFC.

[kvanbrunt2]

any comments on what the service providers like godaddy are doing? i use an x-cart shopping cart that uses ssl for the credit card stuff.

[jack308]

Can anyone tell me the answer to a question I’ve never understood about decryption? Namely, how does one know that you’ve found the correct key to decrypt a target coded message that you are attempting to break?

What criteria is used to automatically determine if you have successfully broken it? For example, if you have a key of only 8 bits you could easily brute-force it and try all 256 combinations. But if you don’t have any fore knowledge of what it contains then how do you know you have been successful?

Is it the appearance of common words like “the”? But what if the message is a series of digits or in a different language? This question has always bugged me and this looked like a good thread to pick the brains of people who might be knowledgeable in the field.

[ShadowAce]

[conservatism_IS_compassion]

Is it the appearance of common words like “the”? But what if the message is a series of digits or in a different language?

Not a computer maven. But I can note that when a German officer raised the issue of how important encryption of radio traffic was to their war operations, he asked if the encryption provisions were sufficient. The reply? “They are German.”

And you know what? I would have thought they were unbreakable, too. Why? Because they consisted of a cypher and a code. A code, meaning a language. Many codes were created for the purpose of data compression in the days of very expensive telegraphy. Six letter codes meaning things like, “lost two funnels in a typhoon” and, “you are about to be arrested. Take it on the lam.” Now if you don’t know the code, and the letters are scrambled before they are sent, how is it possible to know what is in the message????

But the British did it. And now you know why people working at Bletchley Park sometimes went bonkers. Their work was excruciatingly important, and excruciatingly difficult. - yet possible.

[dfwgator]

But the British did it.

You mean the Poles did it.

[rarestia]

FWIW, TLS1.0 is downgradable to SSLv3 and should be avoided as well. At this point, only TLS1.1 and higher are secure ciphers.

[rarestia]

There are dozens of actual encryption technologies. Most of them work through a private key/public key exchange.

When a corporation requests a certificate from, say, VeriSign, a private key is generated for the corporation and is used to “sign” the certificate. When you look at the certificate from the corporation’s side, it shows that they have the private key corresponding to the certificate. This allows them to decipher any traffic encrypted with that certificate.

VeriSign, in the case of this certificate authority (CA), also generates a public key for this same certificate and stores it in their CA database. When the corporation uses the certificate to encrypt traffic to, say, a website, that website is now protected by the private key attached to the certificate, a key that only the corporation should know and be able to use.

When John Q. Public accesses the website, a handshake occurs where the user’s web browser receives the corporation’s public certificate data. The certificate data has a certificate chain which can be used to call to different signing authorities until the user’s system reaches a trusted CA. In most cases, there are no more than 2-3 links in the chain, but I’ve seen some convoluted enterprise CAs that had up to 10. If the certificate data provided from the corporation’s server matches the public key data stored by the CA, a secure session is established, and the corporate server provides a symmetric key to the user to maintain the secure session. This key is randomly generated for every session, so there’s almost no chance of a duplicate key being used.

Since there’s a public/private key exchange available through a trusted certificate authority network, the chances of a key being compromised are low as long as the certificates are kept safe. Most CAs won’t permit a certificate to be exported with its private key outside of the host requesting the certificate. This is highly secure, as it ensures that the requesting machine is the only entity that can use the certificate. If, however, a certificate can be exported with its private key, it’s very possible for that certificate to be compromised, as it would only require a single bad actor to use the certificate while intercepting traffic and acting as a man-in-the-middle.