There is a newly-announced attack on SSL version 3 (SSLv3) called POODLE (Padding Oracle On Downgraded Legacy Encryption). This allows an attacker to steal tokens such as secure HTTP cookies or HTTP Authorization header contents, and then masquerade as the user. More information is available in the paper This POODLE bites: exploiting the SSL 3.0 fallback by Bodo Möller, Thai Duong, and Krzysztof Kotowicz. You can also see the corresponding blog post. Other information sources include the blog post POODLE attacks on SSLv3 (Adam Langley), Dancing protocols, POODLEs and other tales from TLS by Johannes (Hanno) Böck, and Dancing Poodles (Andy Ellis). This vulnerability is much harder to exploit than Heartbleed or Shellshock, but under the right conditions it is still a bad thing. This is not a vulnerability specific to OpenSSL (as Heartbleed was), but instead, any system that uses the original SSLv3 protocol is vulnerable. This paper is part of the essay suite Learning from Disaster.
In many cases the simple solution is to disable support for the hideously obsolete SSLv3. SSL version 3.0 was defined in an internet draft whose last draft version was released on November 18, 1996. The replacement for SSLv3, TLS version 1.0, was defined back in January 1999, and since then the specifications for TLS versions 1.1 and 1.2 have been released. Every protocol update counters known attacks. So POODLE is an attack on a cryptographic protocol that was developed at least 18 years ago, was replaced 15 years ago, and is three versions back from the current TLS protocol. I think 15 years is long enough time for a transition! It’s been known for a long time that SSLv3 has weaknesses and security issues; that’s why TLS superceded it long ago.
Cryptographic algorithms have a limited lifetime, because attackers keep finding new ways to break them. See “Lifecycles of popular crytographic hashes” by Valerie Aurora for a vivid example. The same is typically true of cryptographic protocols like SSL/TLS - attackers will keep finding new ways to break them, so improved cryptographic protocols need to be developed, implemented, and deployed. The real problem is that some suppliers, system developers, and administrators are unprepared for reality - they mistakenly presume that there is no need for easy upgrades.
As is often the case, one of the problems is Internet Explorer 6 (IE6). IE6 does not directly support TLS 1.0 by default. At this point, if you are a user with IE6, it is time to upgrade or switch to a different browser. In particular, note that Windows XP users can install Service Pack 2 (SP2), and then install Internet Explorer 8, or another browser that does support TLS 1.0 such as Firefox. Wikipedia’s article on TLS has more information about web browser support for different versions of the SSL/TLS protocol. Part of the reason that there are still so many IE6 deployments is that people thought that ignoring the standards was okay, and that it was acceptable to develop web applications that only ran on IE6. Now that IE6 is a minority browser, everyone who followed the standards is just fine... while those who wrote IE6-only applications are making their customers vulnerable.
Google recommends supporting TLS_FALLBACK_SCSV as the solution. This prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. However, this is merely a draft - to my knowledge there is no final specification. This also is not universally supported. In contrast, TLS 1.0 is widely supported. Thus, I think requiring TLS_FALLBACK_SCSV is not an immediately useful approach for addressing POODLE.
That said, supporting TLS_FALLBACK_SCSV is a good longer-term strategy. OpenSSL added support for TLS_FALLBACK_SCSV on 2014-10-15, and OpenSSL is widely used. So the good news is that we may see an improved fallback widely implemented.
Each web browser has a different way to disable SSLv3:
Web servers, of course, also have different ways of doing this. Apache server adminstrators can disable SSLv3 using SSLProtocol, e.g., SSLProtocol -SSLv2 -SSLv3 ... where the “...” lists the protocols you do accept. Unfortunately, you’ll have to decide if it’s okay to reject IE6 users.
I like to try to determine what have we learned? Here the lessons are easier.
In particular, it’s a waste of time to focus too much on the technical details of cryptographic protocols. POODLE is an attack on a cryptographic protocol (SSLv3) that was developed at least 18 years ago, and was replaced 15 years ago (by TLS version 1). I think 15 years is long enough time for a transition! Also, the fact that the older protocol (SSLv3) had issues was no secret; that’s why a replacement was created. “How POODLE Happened” (by Daniel Fox Franke, 2014-10-14) has a nice timeline and a brief description of known vulnerabilities in various versions of SSL/TLS.
Instead, I think we can focus on a few real lessons: we need to update and age out cryptographic protocols, ensure that our cryptographic protocols counter downgrade attacks, verify the MAC before doing any cryptographic operation, and use simple version numbering systems.
Cryptographic algorithms and protocols have a lifetime. It is best to update them, have a transition plan, and a timeline to smoothly update them... but they do not last forever. Frankly, it’s absurd that SSLv3 held on as long as it did. The problem wasn’t the protocol, it was the industry’s inability to update. Since SSLv3 we have had TLS version 1.0, 1.1, and 1.2, each of which fixes vulnerabilities and problems in the previous version. Yet there are many systems that do not support protocols beyond TLS version 1.0.
Backwards compatibility is important and valuable. But security issues, and in particular cryptographic algorithms and protocols, are fundamentally different than other things. Because smart attackers look for tiny weaknesses, you have to plan to more-aggressively update to new versions and retire old ones.
We need to ensure that the latest, most secure versions of widely-used protocols are quickly implemented in widely-used implementations (including open source software implementation), and get those deployed on shipping systems.
This is all well and good, but by itself this advice ignores an important reality. Service provider have a significant problem: if their customers do not upgrade, then they must support the obsolete (dangerous) protocols or they risk losing customers. So we need to address this head-on, as described next.
All protocols, both in theory and as implemented, must be specifically designed to prevent downgrade attacks. This is a technical approach, and an important one.
Since cryptographic protocols and algorithms are updated to counter attacks, attackers learned long ago that a great way to subvert systems is to convince them to downgrade to older protocols and algorithms. Then the attackers can reuse the older “fixed” vulnerabilities.
SSL/TLS implementations, unfortunately, were in practice very vulnerable. Since some old servers didn’t originally understand TLS handshakes, the clients implemented a retry without TLS (using SSL instead), under the assumption that the server was so old that it didn’t support TLS. However, this created an easy attack - an attacker could simply block the TLS request, and clients would switch to the more-vulnerable older protocols (SSL) instead. If an attacker can selectively block requests, causing systems to use a different protocol, then it doesn’t matter if there is a more secure protocol; attackers can force systems to use the vulnerable protocol.
Johannes (Hanno) Böck uses the term “evil protocol dance” for this behavior, where a system just keeps trying protocols until it finds something that works. This behavior is reasonable when there are no security issues, but it should never be used for security protocols because it allows downgrade attacks.
In general, if an attacker can force your protocol or its implementation to downgrade to a weaker protocol when it is not necessary, then it is busted.
Here is another technical approach, for those who are interested in the underlying technology.
Moxie Marlinspike recommends a useful rule-of-thumb for designers of secure protocols that he calls the Cryptographic Doom Principle. This principle is, “If you have to perform any cryptographic operation before verifying the [Message Authenication Code (MAC)] on a message you’ve received, it will somehow inevitably lead to doom.” Put another way, always verify the MAC of a message (to detect tampering) before doing anything else with it.
SSLv3 violated this principle; it decrypts before it verifies the MAC. This led to SSLv3 being vulnerable to the POODLE attack (it also creates vulnerabilities to attacks devised by Vaudenay). Moxie Marlinspike states, and I agree, that “subtle crypo mistakes are SO easy to make” - and this is another example.
One absurd problem is that the name and version change between “SSL 3.0” and “TLS 1.0” has led to a lot of security vulnerabilities. Many users presume that 3 is more than 1, and thus, that TLS 1.0 is older than SSL 3.0. The reverse is actually the case; TLS 1.0 replaces the older SSL 3.0. But that absurd name and version change continues to cause grief. For example, Chrome once had a mechanism to enable and disable SSLv3, but they removed it because too many users misunderstood which one was older. The result was that Chrome users (even expert ones) became less safe once POODLE was revealed, because Chrome users had no practical mechanism to disable the vulnerable protocol. Complicated version identification schemes (aka version numbering schemes) make it difficult for users and administrators to properly update their software and their software configurations.
Version numbering should be really simple and clear, yet many other programs make the same mistake. For example, Microsoft Windows is a well known-example of a program that has completely failed to have a simple version numbering scheme.
Another program with a shamefully complicated version numbering scheme is Frama-C. Frama-C is a suite of tools for analyzing software, and it has lot of great features. However, here is the absurd sequence of Frama-C version numbers: Hydrogen, Helium, Lithium, Beryllium, Boron, Carbon, Nitrogen, Oxygen, Fluorine, Neon. So... if you’re running Oxygen, is Neon an upgrade? If you have to think about it (or look it up), your version numbering system is too complicated.
Yet another example of bad version numbering systems is TeX. Since version 3 updates are indicated by adding an extra digit at the end of the decimal to approach pi; The most recent update (on 2014-01-12) released version 3.14159265. This is painful to compare as well.
If you’re ever involved in a program or standard, please just keep the version numbers (and perhaps names) consistent and simple; your users will thank you. People have many things to do each day; keeping track of a complicated versioning system is not something they want to do.
There are various approaches for identifying software versions. What you want is a system that is easy to use, so that it is immediately obvious to everyone which version is older and which version is newer. One reasonable approach is using the release date, often in ISO date format (e.g., 2014-10-24), but this convention has problems if updates of older branches are ever released.
Most people use sequence-based identifiers (such as 1.1) version identifiers, since they easily handle updates of multiple branches. People easily understand them, and many systems already support them as “natural sorting” or “version sorting” (natural sorting sorts sequences of one or more digits in numeric order, not by character code, and may vary other things as well). For more about natural sorting, see posts by David Koelle, Martin Pool, Coding Horror, and Rosetta Code. A useful variant of sequence-based identifiers is semantic versioning (such as 1.1.0). Semantic versioning is clear, and since this format always has 2 periods, version identifiers using semantic versioning cannot be confused with simple numbers. Sometimes version numbers are skipped based on various superstitions (e.g., skipping 4 or 13). Be careful: do not use the pre-release version numbering scheme (with a hyphen) in semantic versioning. Such version numbers are not allowed by practically all Linux package management systems (including rpm-based ones like Red Hat Enterprise Linux, CentOS, Fedora, and SuSE, and deb-based ones like Debian and Ubuntu). Other than its pre-release portion, semantic versioning makes sense.
In 2014 the primary problem with POODLE isn’t technology, nor is the problem really that SSLv3 is vulnerable.
The real problem is that SSLv3 is still supported at all. SSLv3 is a cryptographic protocol with known problems, has been replaced three times with updated and more secure algorithms, and there has been 15 years to transition away from SSLv3. That is plenty of time by any definition. SSLv3 should have no longer been in use.
We need to help and encourage systems to systematically implement updated cryptographic algorithms and protocols, and smartly remove the older and weaker ones. These have a lifetime, just like people do. And just like people, we need to plan for their demise.
If you enjoyed this paper, you might also enjoy the entire suite of related papers in my essay suite Learning from Disaster. This includes similar essays on topics such as Heartbleed, Shellshock, and the Apple goto fail vulnerability. Feel free to see my home page at https://dwheeler.com. You may also want to look at my paper Why OSS/FS? Look at the Numbers! and my book on how to develop secure programs.
(C) Copyright 2014 David A. Wheeler.