Firefox devs mull dumping Java to stop BEAST attacks Firefox developers searching for a way to protect users against a new attack that decrypts sensitive web traffic are seriously considering an update that stops the open-source browser from working with Oracle's Java software framework. The move, which would prevent Firefox from working with scores of popular websites and …
Eclipse being one of the major ones I use. Unfortunately it's fits right in there under "sloth". I have yet to see a major java client app that is all of nimble, usable and and attractive. And as for in-browser applets, and corporate in-house monstrosities - they are just invariably shit.
Blame the developers? If a platform can't deliver the facilities to enable developers to deliver responsive, attractive apps on schedule - that's a problem with the platform much more than the developers. Unless one thinks the very act of learning java puts one in a creative straitjacket ;-)
First, for any confused folks out there: Java and Javascript are completely different things. Java is a statically-typed compiled programming language also used in places other than inside web browsers. Javascript (very similar to the scripting inside Flash) is a run-time typed scripting language used mostly inside web browsers.
"The researchers settled on a Java applet as their means to bypass SOP". Ok, so the guys that showed the exploit chose to use Java to do so. That does not mean that there aren't other ways to do the bypass. What about Javascript? "BEAST injects JavaScript into an SSL session to recover secret information". Sounds like Javascript is more at fault than Java.
Not enough info in the article, but perhaps some of the interfaces available to Java applets make the bypass job easier than other methods. I fail to see why removing Java is a fix for the basic problem. Perhaps removing some specific interface is a better answer. But, if that is done, then make sure that interface is removed from *all* browser API's, especially those available to Javascript. Also anything that can be triggered by the new HTML5/CSS features.
Sounds like the Firefox guys want to be seen to be doing something, and just marking Java as "bad" is the easiest thing they could think of. It certainly doesn't seem like a "right" answer to me.
Javascript may be the real culprit here, but they can't remove that because many many websites would be completely broken without it. Even many of El Reg's pages won't properly display Flash files unless Javascript is enabled (it seems to depend on the author - Lewis's pages require Javascript).
'"The researchers settled on a Java applet as their means to bypass SOP". Ok, so the guys that showed the exploit chose to use Java to do so. That does not mean that there aren't other ways to do the bypass. What about Javascript?'
JavaScript is subject to SOP BEFORE it's run, so crafting JS to bypass SOP is much more difficult to do -- kind of a chicken and the egg problem. Also, since every browser's implementation of JavaScript is different (often even between major versions of the same browser) any discovered exploits of this would likely affect only one or two major versions of one browser.
There are TWO exploits here. The first (the vector) is the exploit of an unpatched Java flaw that allows bypassing of SOP. That requires a fix by Oracle, and they have not been forthcoming about whether/when they will do so. The second (the payload) is the JS injection into the SSL stream.
Even if the BEAST payload didn't exist, the fact that Java allows a means to bypass SOP at all means it can be used to deliver all sorts of nasty exploits. So even though Java is not responsible for BEAST per se, it is currently a weak platform. It is also the only known vector for BEAST at this point, making disabling of it a plausible candidate for a short-term workaround.
Nobody (that I know of) is claiming that disabling Java will resolve the underlying issue with SSL. However, from what I know, that appears to be a weakness with the specification, meaning a complete fix is likely to take some time and effort to implement. So it would be folly not to at least consider ways of minimizing the attack surface in the meantime.
None of my customers is using firefox for business (in the last 5 years), only internet explorer. This idea of corporate using firefox is quite far fetched. Unless they are some weird hippy corporation that hasn't yet learned better (not because firefox has a problem per se, just because a lot of business software still doesn't work 100% properly in it).
As long as Microsoft doesn't block it, it will be fine.
Now for the personal preference: I never felt good about having programming capabilities in a web page. Maybe it's time to let web be as pure html and more advanced stuff be done with flash or silverlight, or as apps.
"This idea of corporate using firefox is quite far fetched"
Not on planet Earth, where there's plenty of companies (including some I do work for) that ban IE and using it to access the web can get you a written warning.
Personally, I rarely switch Java on in any browser I use so this aspect of the BEAST story isn't a big deal.
"Not on planet Earth, where there's plenty of companies (including some I do work for) that ban IE and using it to access the web can get you a written warning."
Really? That's just bizarre, since Firefox doesn't play well with AD & group policy. Surely it's better for users to have up-to-date IE than any old version of Firefox?
If it's such a big issue to prevent use of IE, then the written warnings should go to the network administrator for being too incompetent to stop it...
"Unless they are some weird hippy corporation that hasn't yet learned better (not because firefox has a problem per se, just because a lot of business software still doesn't work 100% properly in it)."
Do you consider Defense (like government) hippy? So speak for yuorself and not what other oraganisations are running!
None of my customers is using IE for business (in the last 5 years), only Firefox. This idea of corporate using IE is quite far fetched. Unless they are some weird hippy corporation that hasn't yet learned better (not because IE has a problem per se, just because a lot of business software still doesn't work 100% properly in it).
"Officially" lots of companies are stuck on IE. Usually this is because of some really stupid past mistakes such as writing / buying tools which use IE controls, or IE JS idioms / HTML quirks which don't work properly on other browsers.
But I bet if you look beyond the surface that many workers would use Chrome or Firefox as their day to day browser and IE for the shitty timekeeping system or whatever. It's also likely that as this internal pressure continues that eventually IT will fix the broken apps or they'll be sure to get a browser neutral replacement the next time around.
The funny part about all these broken internal apps is it probably seemed like such a great idea at the time to develop against one browser but the expense going down the line including replacing this brokenness is probably 10x as much as it would have cost to make the app cross browser compliant in the first place.
To be honest I do exactly that, use IE for work apps and Chromium or Firefox for personal use.
I dont curse the use of IE though, if only because I've been involved in testing and only having to do regression and UAT testing (internal company apps) against one browser on one particular version is infinitely preferable to trying to do it against an ever changing background.
WSUS and IE make it a doddle to ensure you are consistent across your environment.
'Maybe' IE is not the best browser but its not about 'bad decisions' its about your TCO and aggravation levels...
my company delivers FF as standard on all pcs, why. because we have ie6 for some stupid biz app, but we need a real browser for internet access. you may not have heard about this but a lot of business apps run on t'interweb these days. nice idea about a static web tho, someone go tell everyone that html5 is dead, all you really need is word save as html. so will my flash/ silverlight app run on an iPhone?
Firefox is not only supported at work, but embraced. I have one app that will only work under Firefox. The ONLY time I launch Firefox is for that one app.
We have hundreds of users with Firefox installed.
Everything else is IE, which is the default browser.
I use Chrome Portable for browsing at work.
I knew I was going to get a lot of flak for this, but someone had to say it.
So logically i take it there are 26 corporations (thumbs down) possibly who are represented at the register and use firefox? I need not comment more than this.
I wrote my venting post because i've had enough of people promoting firefox and i've had enough testing it in a productive environment always confirming that it still has a quirk here and there. The difference between business and hippy is that business rarely accepts compromise and expects reliability and stability, besides strict integration of a browser in the network policy. I don't mean any public sector or public sector related business. That's a whole different species. And I would also expect that microsoft competitors do not use IE either, duh!
Since citrix would use java to connect for home users from their own machine, 25% of them are likely to be using firefox.
In machines controlled by the IT department, they would be using the citrix client (whether via PNA or a web interface) so java would be immaterial.
(Posted from a site that uses citrix and has lots of firefox installs)
Losing Java would instantly make Firefox incompatible with the online banking site of a major bank in the Nordic region (Danske bank, and its affiliates, fortunately that is not the one my money is in). Probably similar cases exist elsewhere as well.
One could argue they would get what they deserve: there is no real need for such complications, as the bank I use nicely demonstrates: works on almost any browser and OS, JavaScript is optional, and has single-use passwords.
I was just going to say the same thing. Danske Bank took over one of the main Finnish banks (Sampo) and promptly reverted their webbank to something from the 90's. And it now relies entirely on Java for authentication. There was absolutely no need for that and Sampo's previous site worked across all devices. But it is what it is now.
So if they ever did block Java I'm sure most many customers across the Nordic countries would have to give up on Firefox. Never mind all the support calls from extremely confused customers.
Nykredit and a whole host of other banks as well.
Basically, "no Java" pretty much eliminates banking in Danmark.
IIRC, the new National Digital Identity system is Java based (and yes widely criticised for being that - but I digress). So when use of this identity becomes mandated (and it will become so), then there will be no access to any government site, or any vbank, or any insurance company or any ...
Welcome to Danmark.
And on a side note, the former head of the Danish Communist Party, Ole Sohn, a Soviet boot licker and apologist of the worst kind during the 80s and beyond, has just been appointed as the "Minister of Economic and Business Affairs" in a new Left wing coalition Government.
Should browser and httpd makers not simply be focusing on implementing TLS 1.1/1.2? If i recall a previous article mentioned that these were not vulnerable to the exploit. If providers on both sides were to implement this then surely the whole problem goes away (Except for people who don't bother to update, and they're probably already exposed to countless other exploits anyway for not keeping their software up to date.
From previous reports, there are far less dramatic methods of dealing with this problem, and implementing TLS 1.1/1.2 appear to be right at the top of the list. Disabling something that, rightly or wrongly, forms a major part of the internet experience for most people seems overly cautious, and Mozilla really need to look hard at other options.
The problem here is that the server side also needs to support TLS 1.1/1.2, which OpenSSL - probably used in the majority of Apache HTTPS servers - doesn't. If the server only supports up to TLS 1.0, then whatever the client advertises support for, the version will end up downgraded to 1.0 as part of the initial negotiation.
However, since the attack only works with block ciphers in CBC mode, there's a second work-around that could easily be implemented: if the server responds that it only supports TLS 1.0, abort the handshake and start again, prioritising a stream cipher (of which RC4-128 is the only viable option in TLS 1.0, AFAIK). Unfortunately it would have to involve disconnecting & reconnecting, since the client outlines its supported ciphers & their priorities in its opening message (i.e. before it is known which TLS version the server wishes to use) and I think only servers can initiate a renegotiation in-session, but it could be done.
>>>>>>>>>>>>
The problem here is that the server side also needs to support TLS 1.1/1.2, which OpenSSL - probably used in the majority of Apache HTTPS servers - doesn't. If the server only supports up to TLS 1.0, then whatever the client advertises support for, the version will end up downgraded to 1.0 as part of the initial negotiation.
<<<<<<<<<<<<
Yes indeed, but that doesn't excuse Mozilla from implementing TLS1.2. Even MS have that in IE9, it's just that it's not switched on by default. I gather that Opera supports it too.
The sensible solution is to implement TLS1.2 in all browsers. That would allow website operators to upgrade and start mandating it for secure connections without losing their users. A sensible solution has a feeling of inevitability to it, especially if some market-viable browsers already support it. For example, It would be viable right now for online banking sites to say that you have to switch on TLS1.2 in IE9 or use Opera and bar Mozilla and Chrome. It would cause a lot of phone calls, but they could do that right now.
If Mozilla are going to be lazy buggers and say 'not our problem' then Firefox risks getting labelled as being insecure by design. These musings from the Mozilla dev team might be indications that they're not taking the issue seriously, but this is not the first time that's happened.
But if I may get back to your good point about OpenSSL What is the OpenSSL community doing in not supporting TSL1.1/1.2? It's like they've heard of it, agree that it offers better security, but frankly can't be bothered to incorporate it because they've not got the time or inclination. TLS1.2 was defined by RFC5246 in August 2008 (outrageous quoting from Wikipedia). That's more than three years ago. I don't think that that counts as a hearty demonstration of proactive steps to maintain the worth and reputation of their software. They're essentially conceeding that they're quite happy to be outdone by Microsoft...
Our IT department will install Firefox on request. And you can make it work with citrix - sadly you have to login using IE first to it, but after running an app through the citrix client once that seems to sort out the cerftificate on Firefox too. To my mind web stuff should run on any browser without faffing or ballache.
I've been at a company that used citrix before. Getting citrix to work in firefox wasn't a particular problem, not to the extent as mentioned by Dave Perry 2 even. It tries to claim the certificates are out of date when you attempt to log in but it's just a simple matter of exporting your certs from FF and then re-importing them. This refreshes the date on them and suddenly firefox no longer seems to care! This was FF 3.6 i think, was a while ago.
But only firefox is considering dumping java as a result (accepting we don't have access to the email threads internally at microsoft).
If it were me I wouldn't dump it, I'd just put up a bloody great warning every time a site tries to use it (which isn't many sites these days) warning that the plugin has a known security hole and they won't be responsible for the results if you use it.
A lot of people seem to be jumping the gun a bit. Firefox have not said they are going to block Java, they are considering the balance of usability vs security (as they should). It could also be a shot across Oracle's bows to get them to fix the hole in Java. As far as I can see nothing has been decided yet.
Put TLS 1.0 and older versions of SSL on notice and start deprecating them. Additionally do what Google is doing in Chrome and run interference which makes life a lot harder for the tool to figure out what is going on.
I'm sure Java needs to fix something too, but just disabling it for would break far too many sites which use it for one reason or another.
Sigh... Firefox, at the moment nobody could be doing a better job of turning people off your platform. From the ridiculous marketing grab on version numbering, impossible-to-keep-up add-on testing, breaking addons, enforced updates just from checking version, and now breaking scores of sites. I use ADVFN which will be rendered unusable if Java is turned off. I have invested considerable time in getting Firefox set up just right for this and similiar sites.
In short, stop pissing around, let users make their own risk assessments and stop telling users what's good for them. You're making it very hard to stay loyal to what used to be a slick, controllable platform.
Just turn off all ciphers bar RC4. Google have been running with RC4 as the default for years (although for performance reasons not security) and, with it not being cipher block-chaining, it's invulnerable to this attack. It's not as strong as AES, but AFAICT it hasn't been compromised yet. That would give them time to develop a proper fix or browbeat OpenSSL into supporting TLS v1.1/1.2.
But no, let's just make this a rip out features exercise. I can see why they're doing it: They want to make the problem visible so that hopefully someone with nous in the right place will take note.
about:config on existing versions will help you get RC4 only set up client-side. Very easy to enforce with Apache and OpenSSL, too.
How does this help? For an end-user whose bank doesn't use RC4, all your advice will do is force that end-user to switch browser to one that cares less about security.
The problem lies at the server end, but in the meantime we are discussing mitigation that can be applied at the client end. Having said that, disabling Java (until such time as Oracle pull their fingers out) probably leads to the same "browser switch" problem as disabling weak protocols.
I don't think it would be wise to do anything except warn. Specifically, *all* browsers should issue a big fat "This isn't secure." warning against TLS 1.0. Such a statement is factually accurate (so legally safe) and allows end-users to carry on if they are comfortable with the risks.
How hard can it be for web server admins to switch over to TLS 1.1?
Well, if you're administering anything which uses OpenSSL, the answer may be "very", seeing as OpenSSL only supports up to TLS 1.0. There's GnuTLS, but switching to it fully requires the webserver to support it and be compiled to use it. It has an OpenSSL compatibility layer, but I don't know how well said layer works.
We may be about to find out. It's all very well explaining that the world's favourite web servers and browsers are stuck on 1.0, but if 1.0 isn't secure then I'm afraid the general public's response is (eventually) going to be "then get a real server/browser".
In this context, a real web server would appear to be IIS and real browsers would appear to be IE and Opera.
Agreed. I see your point now. Apologies for not recognising it before.
A lot of the discussion on the OpenSSL lists has been met with "we mitigated this in 2006/7 with padding" which really isn't an adequate response. Yes, it may be fixed in OpenSSL itself, but those servers and clients that are relying on its crypto libraries aren't protected by the mitigation.
Using GnuTLS' OpenSSL compat is no use either; you're stuck with exactly the same situation where the calling process knows nothing of its other features. However, we can use mod_gnutls in place of mod_ssl on Apache to get TLS v1.1/2 support. I can see this becoming the solution of choice for Apache users if it delivers what it promises to, although we're still stuck with the client situation. I'm going to have a fiddle with it later on a test box.
http://www.outoforder.cc/projects/apache/mod_gnutls/
As for browsers, it's still either RC4 lockdown or Opera/IE on Windows 7.
Just so everyone knows, mod_gnutls enables TLSv1.1 and 1.2 on Apache 2.2 without any issues. Works fine with IE9 on Windows 7 as long as you enable the two later TLS protocols in Internet Settings. The config is almost 1:1 's/SSL/GnuTLS/g' except that mod_gnutls needs GnuTLSPriorities setting for all virtual hosts.
http://modgnutls.sourceforge.net/downloads/docs/mod_gnutls_manual-0.1.html
"How does this help? For an end-user whose bank doesn't use RC4, all your advice will do is force that end-user to switch browser to one that cares less about security."
In a standard LAMP stack, the switch from AES to RC4 by default is two lines, one if you disable all the other ciphers. Disabling SSLv2 completely is one more They can be globals, so no faffing around in virtual hosts. It helps because RC4 is not vulnerable to this attack.
If the bank in question is too idle, stupid or both to make the necessary config changes, that's their lookout. They're the ones encouraging insecure behaviour, not the browser vendor if they do the right thing. My bank and Paypal, the usual excuses people keep wittering on about, support RC4 128 at least. You just have to tell the browser to prefer it. It is hardly rocket science and is an adequate stopgap measure while the industry tackles this prime example of multiple fail. Disabling various bits of functionality in the meantime is only going to destroy whatever good will the browser vendors have built up for something that isn't entirely their fault.
Oh, and @mangobrain, sticking GnuTLS on a server won't help. It supports TLSv1.1 and 1.2 but only Opera supports it on the client side. What's that, about 2.3% of market share in August? We need OpenSSL support for those protocols soonest. They will then find their merry way into at least Fx, Konq and Chromium.
"Oh, and @mangobrain, sticking GnuTLS on a server won't help."
Not on its own, no - that was in response to Ken Hagan's "how hard can it be" question. Although, in a rare twist, IE8 and 9 supposedly support it on the client side as well - albeit not enabled by default (at least, not on my machine). OpenSSL support is definitely needed.
Just make a bloody decision; don't whine about how you don't know what to do, can't decide, can't balance out the pro's and con's, all the while leaving users exposed.
Simply block Java on a site by site basis, allow the user to enable it for all sites or specific sites, and end of story for now. If using Facebook or any other site necessitates enabling Java, puts the user at risk, then that's the user's or site's problem, not Mozilla's.
It's no different than what to do when a link is suspected of being malicious: Always allow it to be clicked ? Block it ? No; warn the user, let them decide what to then do. It's the only option anyway at present because there is no other single 'right answer', as Mozilla seem to have already recognised so it makes debate on what to do pretty pointless, mere procrastination.
I hope this shower never take on jobs as firemen because the house would likely burn down before they can decide whether water should be used as that might damage the contents.
re:Jason Bloomberg
And then someone finds a way to do the same hack using Flash so we block that to. And then pure Javascript so we block that to... not very clever right?
The problem has been know for six years at least. The concept of altering data in an encrypted stream much longer. Mozilla has f-up doing pointless UI changes instead of making a secure browser. Implement TLS1.2 and show a nasty warning for any server requesting old/broken solutions/cipher is what they should do.
you can transfer cookie data as a encrypted string from user to server, and decode it serverside when needed, null nuke uses a dodgy tweaked pure php code cipher from a mailbox class, you can replace using a php blowfish module function or whatever, php encryption omdules are no good at short strings and wont work on time() in a cookie
serverside decryption key is wrong, then cookie decode returns null and the user gets logged out
all websites can do the same as a quick fix
It isn't like Java is the multi-platform ActiveX; Java has its own security sandbox, unlike ActiveX. The real problem is the cypher protocol implementation; people should be already implementing/migrating to TLS 1.2 already.
If Mozilla were truly worried about Security, they would be disabling *Javascript*, of course.
"Java has its own security sandbox"
Evidently not a good enough sandbox, since it was the attackers' chosen vehicle for getting around the SOP.
It's a shame really. The original design objective of the JVM (not the language) was to produce something that could be proven secure, at least in the same sense that a proper OS is secure against privilege escalation attacks from user-level programs. The whole project, then, *should* have been a case of re-inventing the wheel. I suspect, however, that once client-side Java failed in the marketplace, the security people lost influence to those trying to re-invent Java as a server-side language.
Better idea: Get Rid Of Usless Javascript Now!
All these &^%$ing hijacks go away if you don't author at the browser at run-time.
All it does is bring Teh Shiny. Only a fool does any useful work at the browser end of the transaction.
Get rid of this digital psoriasis, this boil on the backside of the web, this cowpat in the field of IT.
Mozilla is known to be one of serious open source organizations.
The "bug" reported is not a bug, it isn't a rfe either. It is a well written rant abusing bugzilla bug reporting system.
The reporting person is so much disconnected from real, business World that he can actually suggest it. I know COUNTRIES depending on Java for their citizens to logon to government. I don't even need to repeat banks and military, largest enterprises.
This rant has caused so much harm to their image on corporate World, even more than "we will become like Chrome" policy. I really think they should review the reporters background especially regarding to the only Java competition, .NET and its producer, Microsoft.
Bug should have been closed, purged just for single reason. Mozilla policy (and many others) forbids talking, reporting security related issues (even remotely) at publicly accessible bugzilla. Even people who hates them, competes them (MS) respected it so far.
It is really childish amateur to rant like that on any project of that scale. I really think there should be some Oracle/Sun employees and managers that would return their calls or e-mails.
"The "bug" reported is not a bug, it isn't a rfe either. It is a well written rant abusing bugzilla bug reporting system."
Bugzilla is used for handling a wide variety of Mozilla matters, down to adding blogs to the Planet Mozilla feed. It is not an exclusive bug/RFE reporting tool.
"This rant has caused so much harm to their image on corporate World"
Did the corporate World (sic) ring up and tell you? I'm part of the Mozilla Enterprise Working Group and I can tell you nobody is having a heart attack.
"Mozilla policy (and many others) forbids talking, reporting security related issues (even remotely) at publicly accessible bugzilla"
Nonsense. Some issues are labelled as private when it's relevant to do so, for only as long as it is required to do so. That is general prudence.
"It is really childish amateur to rant like that on any project of that scale."
Anyone is welcome to suggest an item for discussion. It does not mean anything other than somebody felt they should suggest that item for discussion. You're reading way too much in to it.
My suggestions:
1. As a workaround, Firefox and other browsers should, prefer RC4 for all the retarded websites which only support SSL3.0 and/or TLS1.0, and throw up an exploitable SSL warning banner if a website can't support this workaround!
2. Java is not the problem, the browser Javascript implementation is where the exploit occurs, so fix it Firefox devs e.g. learn from the Noscript extension and provide proper layered security for Javascript!
3. Oracle or Mozilla could implement a custom Java Security Manager to block this in Java, and look at securing all the other plugin vehicles e.g. Flash!
4. We need a campaign to shame retarded SSL library devs, webserver devs and website admins into supporting secure versions of TLS; via an insecure SSL version notifications in Firefox and other browsers for inadequate SSL support e.g. only SSL3.0 and/or TLS1.0!
5. Noscript also needs to be update too, because the permissions are still too global for plugins and should support custom individual site plugin permissions too!
I'm sorry, I can't be arsed to run the Krypton factor obstacle course every time I visit a new site.
I think the main problem is that someone (either OpenSSL or the browser makers) must take the first step in supporting TLS 1.1 and 1.2 and throwing up a huge error message for TLS 1.0 without RC4.
If Microsoft are as bothered about security as they make out then they should backport TLS 1.1 and TLS 1.2 to Vista and XP and push it out as a mandatory update (one of those which you can't even refuse).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
