Oracle updates Java to stop SSL-chewing BEAST
Framework declared safe for Firefox
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Firefox developers said Tuesday that they have no plans to keep the browser from working with the Java software framework now that Oracle has released a patch that prevents it from being used to decrypt sensitive web traffic.
In a blog post published in late September and updated on Tuesday, Mozilla recommends that Firefox users update their Java plug-in to lower their chances of falling victim to attacks that silently decrypt data protected by the SSL, or secure sockets layer, protocol used by millions of websites. Firefox developers had said previously that they were seriously considering disabling the Java plug-in as a way of preventing the exploit.
Short for Browser Exploit Against SSL/TLS, BEAST was first demonstrated late last month at a security conference in Argentina, where researchers Juliano Rizzo and Thai Duong used the attack to recover an encrypted authentication cookie used to access a PayPal user account in less than two minutes. Oracle has more about the Java update here.
Their attack exploits a vulnerability in version 3.1 of SSL and version 1.0 of the SSL successor known as TLS, or Transport Layer Security. To make their code work, they needed a means to breach what's known as the same-origin policy, a mechanism built into browsers that prevents websites set by one domain from accessing or modifying data set by another site. Rizzo and Duong ultimately employed a Java applet that exploited a same-origin policy flaw in Oracle's software framework.
The possibility of real-world attacks that silently recovered authentication cookies, social security numbers, and other sensitive data encrypted by SSL was troubling enough to Firefox developers that they considered blocking Java plug-ins in the open-source browser. The move could have caused a variety of serious problems for users, because it would have prevented their browsers from working with virtual private networks, intranet tools, and web-conferencing applications such as Cisco Systems' WebEx.
“We will not be blocking vulnerable versions of Java at this time, though we will continue to monitor for incidents of this vulnerability being exploited in the wild,” Mozilla said in Tuesday's update.
But Java isn't the only way to bypass the same-origin policy, so it doesn't foreclose the possibility that Rizzo and Duong's exploit won't be carried out using other means.
“There will be other methods for doing this, so it doesn't fix the BEAST attack itself,” Nate Lawson, a cryptographer and principal of Root Labs, told The Register. “You need a TLS/SSL fix for that.”
Firefox developers, often working with developers of Google's Chrome browser, have experimented with other ways to stop BEAST attacks. Beta versions of Chrome, for instance, split messages into fragments to reduce an attacker's ability over the plaintext about to be encrypted.
As Lawson pointed out, a more effective fix would be for all websites and browsers to update to TLS 1.1 or SSL 3.2 or higher. Making the transition has proved extremely problematic because huge numbers of websites and browsers will fail to work as expected unless everyone upgrades all at once. ®
COMMENTS
Great idea in theory, unworkable in practice for many businesses due to cost. For instance, IIS6 cannot support TLS 1.1 or higher (unless MS decide to release a free patch for schannel to support it which is unlikely), MS would be rubbing their hands in glee as they'll look to businesses to move all those sites to IIS7.5 on Windows 2008 which does support TLS 1.1 and 1.2 already. Add to that the time to test upgrades, migrate applications, provision new hardware, and train staff to support another version of Windows, and it's clear that it's not a small tweak to turn this on. In an ideal world MS would release a patch for schannel on Windows 2003 to add this to IIS6, but I seem to have left my rose-tinted glasses at home.
Moving to open source might help (say using Apache 2 on nix with mod_gnutls, as mod_ssl doesn't support TLS 1.1+ yet), but the cost of moving from Windows to nix might be more than simply going to Windows 2008 - it all depends on the IT dept capabilities and whether applications can be ported. A free OS doesn't mean that there's no cost implications. Moving to Apache on Windows 2003 won't help because the Win32 port uses the Microsoft Crypto API for SSL/TLS support, and that doesn't have TLS1.1+. Catch 22.
Short term making stream ciphers (such as RC4) preferential in the Windows crypto settings, or in the case of Windows 2003 disabled the CBC cyphers (you can't set a preferred order, just enable or disable cyphers individually), eliminates this vulnerability at the server side and doesn't appear to break anything (at least not that I've seen as yet).
Here's the egg.
Why hasn't Mozilla and company pushed support for TLS 1.1 and such ALREADY? And supporting TLS 1.2 is non-trivial since there are numerous implementation changes such as changing over to SHA-256.
Brilliant...
Glad I haven't just finished updating our whole estate to 6_27
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
