Browsers tackle the 'BEAST' Web security problem
Mozilla considers disabling Java in Firefox as a solution to a weakness with the Transport Layer Security protocol used for accessing sensitive Web sites.
Browser makers are devising ways to protect people from a security protocol weakness that could let an attacker eavesdrop on or hijack protected Internet sessions. Potential solutions include a Mozilla option to disable Java in Firefox.
The problem--considered theoretical until a demonstration by researchers Juliano Rizzo and Thai Duong at a security conference in Argentina last week--is a vulnerability in SSL (Secure Sockets Layer) and TLS (Transport Layer Security) 1.0, encryption protocols used to secure Web sites that are accessed using HTTPS (Secure Hypertext Transfer Protocol).
Here are responses from representatives of the major browsers:
"We are currently evaluating the feasibility of disabling Java universally in Firefox installs and will update this post if we do so," a Mozilla Security blog post says. "Firefox itself is not vulnerable to this attack. While Firefox does use TLS 1.0 (the version of TLS with this weakness), the technical details of the attack require the ability to completely control the content of connections originating in the browser, which Firefox does not allow. The attackers have, however, found weaknesses in Java plug-ins that permit this attack. We recommend that users disable Java from the Firefox Add-ons Manager as a precaution."
"We consider this to be a low risk issue for customers, but we released Security Advisory (2588513) to provide guidance and protection for customers with concerns," Jerry Bryant, group manager of Response Communications at Microsoft Trustworthy Computing, said in an e-mail. To be clear, Internet Explorer depends on the Windows implementation of these protocols, so our mitigations and workarounds apply to the operating system and not the browser. We are looking at other ways to address the issue both in our products and within the industry and will update our guidance as it becomes available."
A Google representative referred CNET to a blog post from late last week written by Adam Langley, a member of the Chrome team, that said the company was preparing and testing a workaround. "The attack is still a difficult one; the attacker has to have high-bandwidth MITM access to the victim. This is typically achieved by being on the same wireless network as the victim," the post says. "Nonetheless, it's a much less serious issue than a problem which can be exploited by having the victim merely visit a Web page. (Incidentally, we pushed out a fix to all Chrome users for such a Flash bug only a few days ago.)"
Opera developed a fix and tried shipping it in Opera 11.51 but found that changes made to how the browser connects to servers were "incomprehensible to thousands of servers around the world," Opera's Sigbjorn Vik wrote in a blog post. "This issue will have to be solved in close cooperation between browser vendors and Webmasters. Since this cannot be directly exploited in Opera, we decided to wait until we have an industry agreement on how to move forward. We have test systems in place which can connect to millions of secure sites around the world and detect how these sites will react to changes to the protocol. We will be sharing our results from these test runs with other browser vendors and affected parties, to give us a good basis for finding the best solution to the issue."
Apple representatives did not respond to e-mail or telephone requests for comment about the Safari browser.
Just upgrading to TLS 1.1, which is not vulnerable to the threat, won't work because nearly all SSL connections use TLS 1.0, according to a Qualys study reported on by Dan Goodin at The Register, which broke the BEAST story. In addition, "upgrading TLS is proving surprisingly difficult, mostly because almost every fix breaks widely used applications or technologies," he wrote.
Addendum, September 30, 11:50 a.m. PT: CNET asked both Mozilla and NoScript creators if the NoScript Firefox plug-in would protect against a BEAST-type of attack and did not hear back by midday Friday. However, researchers at PhoneFactor, who have released a whitepaper on how to mitigate the threat, said NoScript could help.
"NoScript will mitigate BEAST if both:
A. The site is serving everything securely over https. I.e., no "mixed content warning" on the page.
B. The user knows there should not be mixed secure/insecure content and would refuse to run any if the bad guy offered it to him," said Marsh Ray, senior software engineer at PhoneFactor.
"This is a lot to ask of any user. I run NoScript all the time and I don't know that I would pass the test myself," he said in an e-mail. "But in practice, users with NoScript are still going to be miles ahead of users without it when the malicious applet comes around. It will require the attacker to have planned in advance to target that specific user, likely saving the user from anmass network attack."
Addendum, October 3, at 8:51 a.m. PT: Giorgio Maone, founder of NoScript creator InformAction, said the program would protect users from a BEAST attack in most cases because untrusted plug-ins are disabled until a user authorizes them one by one. "However, users that are in a potentially hostile network (e.g. a rogue ISP, proxy or public Wi-Fi) should also raise the 'NoScript Option|Advanced|Forbid active web content unless it comes from a secure (HTTPS) connection' setting to the appropriate level, even though this means browsing non-HTTPS website[s] may become quite painful," he said. More information is available on the InformAction forum.