The latest in 2014’s saga of server-side issues is POODLE, an acronym of Padding Oracle On Downgraded Legacy Encryption (otherwise designated as CVE-2014-3556) that was named by the publishers of the disclosure, Google researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz.

POODLE is a flaw in how browsers handle encryption; by negotiating down to SSL 3.0, attackers can alter padding data at the end of a block cipher in a way that forces a slow leak of data. Many of the cipher suites in SSL 3.0 have already been abandoned as insecure, due to small key sizes, biases, and simply having support already removed from browsers.

The POODLE vulnerability allows attackers to exploit the design of SSL 3.0 to decrypt sensitive information, including secret session cookies (and, therefore hijack sessions for users’ accounts). Because the exploit is not being a patchable flaw, it is necessarily hastening the death of SSL 3.0 as a viable standard.

In finer detail, from Möller, Duong, and Kotowicz:

Encryption in SSL 3.0 uses either the RC4 stream cipher, or a block cipher in CBC mode. RC4 is well known to have biases, meaning that if the same secret (such as a password or HTTP cookie) is sent over many connections and thus encrypted with many RC4 streams, more and more information about it will leak. …Unlike with [other] attacks, there is no reasonable workaround. This leaves us with no secure SSL 3.0 cipher suites at all: to achieve secure encryption, SSL 3.0 must be avoided entirely.

The paper goes on to describe a workaround in the event that SSL 3.0 must absolutely remain for compatibility with legacy systems — the exposed systems are unpatched, unsupported versions of Windows XP and Internet Explorer 6 — using TLS_FALLBACK_SCSV to head off the handshake portion of the exploit, though it does not do anything to fix the underlying and preexisting cipher issues. To summarize, the SCSV fix sends a flag if a client system is being forced to downgrade for a connection the server should be capable of supporting.

In all fairness, SSL 3.0 was replaced by TLS 1.0 in 1999 — it is time for the standard to be deprecated.

The public response

Akamai, a popular CDN, has accelerated its deprecation of SSL 3.0, which at present stands at 90% complete, and should be finalized for Secure CDN customers by late October to early November 2014. The firm is also working on a phased deployment for TLS_FALLBACK_SCSV for legacy systems, though they note that since few browsers support this patch, it does not help anyone for the short term. SSL 2.0 traffic is now blocked, and customers supporting only SSL 3.0 are urged to upgrade as soon as possible.

CloudFlare has disabled SSL 3.0 support by default for all customers. Business and enterprise customers have the option of enabling it manually, though CloudFlare strongly discourages users from doing so. The company’s research notes that for HTTPS traffic, only 0.65% of this traffic uses SSL 3.0, which they characterize as being mostly attack traffic and crawlers. They also note that Windows XP traffic constitutes only 3.12% of all “real visitor traffic,” and of those users, only 1.12% use SSL 3.0.

Twitter announced an immediate end to SSL 3.0 support for its services, forcing users to use a browser that supports TLS 1.0 or higher.

Mozilla rolled out an extension for users to immediately disable SSL 3.0. SSL 3.0 will be disabled by default in Firefox 34, which will be released on November 25, 2014. Plans are also in the works to include support for SCSV in Firefox 35.

Möller indicated in a Google blog post that Chrome has supported SCSV since February 2014, and that SSL 3.0 support will be removed completely from client products “in the coming months.”

Does this dog bite?

What, if any, precautions will you take to mitigate this issue? Do you still have production servers that support SSL 3.0? Let us know your thoughts in the comments.

Disclaimer: TechRepublic and ZDNet are CBS Interactive properties.