[..]
Yeah - this is a hard call. Killing Java means disabling user functionality like facebook video chat, as well as various java-based corporate apps (I feel like Citrix uses Java, for instance?)

We do have soft-blocking now, which disables but prompts with the option to re-enable, and also allows users to re-enable from the addons manager, but it still means it's dead for most people. Click to play or domain-specific whitelisting will provide some measure of benefit, but I suspect that enough users will whitelist, e.g., facebook that even with those mechanisms (which don't currently exist!) in place, we'd have a lot of users potentially exposed to java weaknesses.

Whatever decision we make here, I really hope Oracle gets an update of their own out - it's the only way to keep their users affirmatively safe.

Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that's passing between a webserver and an end-user browser.

The vulnerability resides in versions 1.0 and earlier of TLS, or transport layer security, the successor to the secure sockets layer technology that serves as the internet's foundation of trust. Although versions 1.1 and 1.2 of TLS aren't susceptible, they remain almost entirely unsupported in browsers and websites alike, making encrypted transactions on PayPal, GMail, and just about every other website vulnerable to eavesdropping by hackers who are able to control the connection between the end user and the website he's visiting.

At the Ekoparty security conference in Buenos Aires later this week, researchers Thai Duong and Juliano Rizzo plan to demonstrate proof-of-concept code called BEAST, which is short for Browser Exploit Against SSL/TLS. The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses to grant access to restricted user accounts. The exploit works even against sites that use HSTS, or HTTP Strict Transport Security, which prevents certain pages from loading unless they're protected by SSL.

The demo will decrypt an authentication cookie used to access a PayPal account, Duong said. Two days after this article was first published, Google released a developer version of its Chrome browser designed to thwart the attack. Update here.

Like a cryptographic Trojan horse

The attack is the latest to expose serious fractures in the system that virtually all online entities use to protect data from being intercepted over insecure networks and to prove their website is authentic rather than an easily counterfeited impostor. Over the past few years, Moxie Marlinspike and other researchers have documented ways of obtaining digital certificates that trick the system into validating sites that can't be trusted.

Earlier this month, attackers obtained digital credentials for Google.com and at least a dozen other sites after breaching the security of disgraced certificate authority DigiNotar. The forgeries were then used to spy on people in Iran accessing protected GMail servers.

By contrast, Duong and Rizzo say they've figured out a way to defeat SSL by breaking the underlying encryption it uses to prevent sensitive data from being read by people eavesdropping on an address protected by the HTTPs prefix.

“BEAST is different than most published attacks against HTTPS,” Duong wrote in an email. “While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests.”

Duong and Rizzo are the same researchers who last year released a point-and-click tool that exposes encrypted data and executes arbitrary code on websites that use a widely used development framework. The underlying “cryptographic padding oracle” exploited in that attack isn't an issue in their current research.

Instead, BEAST carries out what's known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks.

If the attacker's guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.

At the moment, BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their PayPal attack (the demo will decrypt an authentication cookie used to access a PayPal account) to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of Duong and Rizzo's claim that this time can be drastically shortened.

In an email sent shortly after this article was published, Rizzo said refinements made over the past few days have reduced the time required to under 10 minutes.

“BEAST is like a cryptographic Trojan horse – an attacker slips a bit of JavaScript into your browser, and the JavaScript collaborates with a network sniffer to undermine your HTTPS connection,” Trevor Perrin, an independent security researcher, wrote in an email. “If the attack works as quickly and widely as they claim it's a legitimate threat.”

Mozilla and OpenSSL: 'It's terrible, isn't it?'

Duong and Rizzo said the underlying vulnerability BEAST exploits is present in virtually all applications that use TLS 1.0, making it possible to apply the technique to monitor private communications sent through many instant messenger and Virtual Private Networking programs.

Although TLS 1.1 has been available since 2006 and isn't susceptible to BEAST's chosen plaintext attack, virtually all SSL connections rely on the vulnerable TLS 1.0, according to a recent research from security firm Qualys that analyzed the SSL offerings of the top 1 million internet addresses.

Chief culprits for the inertia are the Network Security Services package used to implement SSL in Mozilla's Firefox and Google's Chrome browsers, and OpenSSL, an open-source code library that millions of websites use to deploy TLS. In something of a chicken-and-egg impasse, neither toolkit offers recent versions of TLS, presumably because the other one doesn't.

“The problem is people will not improve things unless you give them a good reason, and by a good reason I mean an exploit,” said Ivan Ristic, Qualys's director of engineering. “It's terrible, isn't it?”

While both Mozilla and the volunteers maintaining OpenSSL have yet to implement TLS 1.2 at all, Microsoft has performed only slightly better. Secure TLS versions are available in its Internet Explorer browser and IIS webserver, but not by default. Opera also makes version 1.2 available but not be default in its browser.


Ristic, who presented his findings at the Black Hat security conference in August, has found additional evidence that websites often delay deploying upgrades that fix SSL security holes. His analysis found that as much as 35 percent of websites had yet to patch a separate TLS vulnerability discovered in November 2009 that made it possible to inject text into encrypted traffic passing between two SSL endpoints.

Researches said upgrading TLS is proving surprisingly difficult, mostly because almost every fix breaks widely used applications or technologies. A technology recently added to Google Chrome that significantly reduces the time it takes websites to establish encrypted connections with end-user browsers is just one example, said cryptographer Nate Lawson, principal of the Root Labs security consultancy.

Duong and Rizzo said there are many more examples.

"Actually we have worked with browser and SSL vendors since early May, and every single proposed fix is incompatible with some existing SSL applications," Duong wrote. “What prevents people is that there are too many websites and browsers out there that support only SSL 3.0 and TLS 1.0. If somebody switches his websites completely over to 1.1 or 1.2, he loses a significant part of his customers and vice versa.”