Slashdot Mirror
To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework
rastos1 writes with this news from The Register: "In a demonstration last Friday, it took less than two minutes for researchers Thai Duong and Juliano Rizzo to wield the exploit to recover an encrypted authentication cookie used to access a PayPal user account. ... The researchers settled on a Java applet as their means to bypass SOP, leading Firefox developers to discuss blocking the framework in a future version of the browser. ... 'I recommend that we blocklist all versions of the Java Plugin,' Firefox developer Brian Smith wrote on Tuesday in a discussion on Mozilla's online bug forum. 'My understanding is that Oracle may or may not be aware of the details of the same-origin exploit. As of now, we have no ETA for a fix for the Java plugin.'"
I have to say I am actually surprised to see how many people still have a Java plugin for their browsers. I had a look at the analytics of my website and it looks like more than 80% of my visitors have one.
I heavily use Java on the desktop (Eclipse, etc) and on my servers (Tomcat) but I thought Java Applets to be dead for long.
Write boring code, not shiny code!
How about a simple warning before loading a Java Applet? For example, one of those yellow bars at the top of the page? That would prevent all legitimate applets from being instantly unusable in Firefox, whilst providing some security.
The viability of the BEAST attack is totally overblown. The attacker must be a man-in-the-middle and control a website that you visit in order to have any chance of getting a cookie/password/thing-of-value that it must already be able to guess. The actual attack is merely defeating the CBC in order to encrypt the guessed value in precisely the same way as the target value, allowing you to compare to see if the encrypted data are equal.
Indeed, image doesn't enforce "same origin" either, and the server (of the frame) can stil introduce the needed padding into the URL...
...and will further put a stake into the heart of Java in the web.
Uh, Linux geek since 1999.
Web browsers are good for viewing static documents, especially ones that link to other static documents.
Time and time and time again, however, they have been shown to be horrible at hosting more complex applications and interactive functionality.
It doesn't matter which embeddable application technology we consider, they are all rife with security flaws. Java applets, ActiveX controls, JavaScript, Flash, and browser plugins (like PDF viewers) have all suffered from numerous security problems.
If you need to provide your users with application-like behavior, then just write a native application!
Browsers are not operating systems. They are not good at hosting applications in a secure manner. Even after two decades of trying, they still aren't suitable environments for hosting applications. It's looking like they never will be, either.
You seem to think that OSes have fared any better. The only reason that exploits come primarily through the browser is because it is far simpler to get a user to run a website/webapp than to download and run a native application. Remove the capability of the browser and force the user's hand into running native applications (and attackers into exploiting them) to do the things he/she wants and your idea of the mighty, secure OS will quickly evaporate.
You know, the issue here is not the browser. It's the HTTP protocol - it was simply designed for nothing else but static content. The number of kludges and patches you need to implement basic session handling and interactvity is getting ridiculous. Do we even have a RFC for cookies, for example?
If you need to provide your users with application-like behavior, then just write a native application!
When there was just one popular platform to run these native applications on, this was a fine solution. I mean back when everybody did everything in Windows. But nowadays, people are using all sorts of systems. Not just Mac OS X and Linux on the desktop, but iOS, Android, Windows Phone, BlackberryOS and Symbian on mobile devices as well. So "just write a native applications" actually becomes "write a native applications and then port it to 7 other platforms". That's when a web application suddenly starts to look like a viable alternative.
Pretty good is actually pretty bad.
I have convinced several non-technical people to stop using IE all together when I could conclusively show them that there was no practical way to disable the Java plugin... Choir preaching over.
While Firefox and Chrome allow practical and real disabling of the Java functionality in their browsers, only Chrome offers really practical functionality for plugins (yes, I'm aware there are several other browsers out there that people deeply love, however testing in the above three tend to give proper rendering on all for web elements, so I don't plan on expanding my repertoire).
In Chrome, if the Java (or Windows Media Player, etc.) plugin is requested by a page, users are prompted to give domain specific permanent access to the plugin or allow it for one-time use. As ridiculously problematic as Java is from a security perspective, it is also extremely useful for enterprise-level products that use it exclusively for powerful web-based back ends (Cisco firewalls for one).
Nowadays you have a lot of options to ease code porting - including the allmighty "write once, run everywhere" Java. Lately i've been working a lot with Python and i'm amazed of how painless it was to port apps between Windows and *nix (i.e, no pain at all).
You know, the issue here is not the browser. It's the HTTP protocol - it was simply designed for nothing else but static content. The number of kludges and patches you need to implement basic session handling and interactvity is getting ridiculous. Do we even have a RFC for cookies, for example?
The only flaw with HTTP is that it is stateless. It is also its greatest strength.
I'd hardly call cookies 'number of kludges and patches' though. Ah, here is the RFC: http://www.ietf.org/rfc/rfc2109.txt
Write boring code, not shiny code!
Okay. Now try porting it to iOS. Or ChromeOS. Or WebOS. Or Blackberry.
I'm gonna bet WP7 and Android wouldn't be painless, either. And good luck getting people to install Python on their Windows box before they can even try your app.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
What is with all of the over-the-top craziness coming out of Mozilla recently? Oracle needs to address the bug, but maybe Firefox could handle it in a more graceful manner than disabling the plugin entirely.
Mozilla, you used to be one of the darlings of open source, now you're turning into a crazy cat lady.
- remove version numbers.
- rapid release schedule breaks add-ons.
- gave the middle finger to enterprise users.
- removed the URL bar.
Web browsers are good for viewing static documents, especially ones that link to other static documents.
Yep, but in the past 10 years they've gotten damn good at other things too beside hosting a page with the blink tag. Frankly I don't miss the days of a static web page.
It doesn't matter which embeddable application technology we consider, they are all rife with security flaws. Java applets, ActiveX controls, JavaScript, Flash, and browser plugins (like PDF viewers) have all suffered from numerous security problems.
The same could be said for nearly every application written in any other language. Security is something that needs to be applied from the ground up whether you're designing a database front end designed to run in a web browser or writing a simple native program in C.
Even after two decades of trying, they still aren't suitable environments for hosting applications. It's looking like they never will be, either.
Two decades of trying? Just when do you think Web2.0 actually took off? The proliferation of the browser as an end user environment has really only been popular for less than a decade unless you count the HTML tag that found its way onto every site during the dotcom bubble an application.
You said the environment isn't suitable, I say I'd rather take it with it's standard OS type model of find flaw, fix flaw, rinse repeat then go back to a world of having to find a different bloody native application on every different operating system to do essentially the same function often over a lovely proprietary protocol.
Thanks for the RFC reference. Cookies are perhaps the most painless aspect of "modern" HTTP dev work; i was aiming more at atrocities like AJAX.
That IS the problem with browsers. It's like allowing executable code in a data document - it's something that SHOULD be safe but isn't.
Way to further decrease market share. First start fuck with the versions numbering. Now blacklist java.
Keep taking the express elevator to the bottom, just like Netscape did.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
So they want to block Java over what is a difficult to execute attack that has some serious requirements to even use... but they continue to allow Flash with it's critical flaw of the week that's being actively exploited?
Is this a joke? Flash is the single largest attack vector on the entire fucking Internet.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Spyware/malware used to be much more of a pain because you had to download and trust a large number of applications to do much with your computer. Many user's needs are sandboxed into webapps these days, preventing a lot of issues.
Meh. If your application is primarily presenting a UI then a web app isn't such a bad solution. For applications that actually do something, most of the work is behind the scenes. If it's Desktop only write it in Python or the like and you've suddenly got the entire desktop/notebook market finished. If you want it to run on a phone or tablet (and it SHOULDN'T run on both a phone and a desktop) then write it in C and slap Android and iOS UIs on it.
PyObjC. It's completely doable.
And even then, it is not the desired target. If you use the right tools for each platform it gets way easer; Java paves and easy road for porting between desktops, Android, iOS, Chrome and Blackberry, for example.
A Java application does not run on Windows Phone 7. Only web applications and applications written in verifiably type-safe .NET languages work on Windows Phone 7, and Microsoft has ended support for J# as far as I know. Python doesn't work on a lot of these more locked-down platforms either: it and other DLR languages require Reflection.Emit, which isn't present on a lot of the minimal CLRs. Nor will Java or Python help you get Sony or Nintendo to approve your application for execution on a PSP, PS3, PSVita, DSi, Wii, or 3DS, all of which come with a web browser or have one available for download at no charge.
If you need to provide your users with application-like behavior, then just write a native application!
Give me a solid workaround for each of these problems and I'll agree with you:
Quoting decoder from the security team:
"It should be "click to play" by default, which means you have to click on the applet for it to be activated and loaded. "Disabled" might have been the wrong term here, but until you click the applet, nothing can happen."
That's what Chrome does also. Then again in theory, flash should also be click to play. Except flash is used everywhere and its going to piss people off, so its not click to play, either in Chrome. In fact, all plugins should be click to play with a white list of auto play sites that the user can configure. Yeah, Noscript.
Still, I'd prefer default click to play in java.
Ajax conforms to the HTTP protocol pretty much like everything else. It is an http request sent by the browser basically indistinguishable from another regular http request to get an image or an html file. Nothing was done in the HTTP protocol for AJAX. What are you talking about exactly?
Write boring code, not shiny code!
WebSocket is developed to shine where HTTP fails. It's not yet ready for the masses, but Firefox 4, Opera, Chrome and Safari already have some support. WebSocket will make Ajax and polling in general a thing of the past, enabling even more application-like behaviour in your browser.
Pretty good is actually pretty bad.
Java is slow for the first applet you view in a browser session. After that, the important class libraries are already in RAM, and further applets load just as fast as, say, SWF objects.
You can bundle a python interpreter and app up so that installation and execution are the same as any other app.
Makes for a larger install package, but that's about it.
Nerd rage is the funniest rage.
we have to make sure there are safeguards in place like [...] maybe requiring approval for plugin installation from someone with the smarts to know better than to install [a trojan disguised as a video player component]
So how would a more knowledgeable PC owner prove he has "the smarts to know better" in order to approve a plugin installation?
He's probably talking about things like how the browser/web server create a new TCP session for each and every AJAX request, even if they're going to happen every few seconds for as long as you're on a page. Google gets around this by setting some silly-long keep-alive on the TCP connection for the original page request on pages like gmail so the first few AJAX requests at least don't take the extra overhead.
I guess that means they haven't decided if it should go in the version 8 due after lunch, version 9 tomorrow morning, or version X next Tuesday . . .
The attacker must be a man-in-the-middle
The server's ISP is a man-in-the-middle. The operator of a national firewall is a man-in-the-middle. This is not unlike what Perspectives calls the "Lserver attack".
I'm talking the fact that you need to execute an HTML call in scripting language inside the same browse to retrieve HTML content which most of the times requires a framework tool in order to be reprocessed and inserted into the main pages' DOM. It's a (very ugly) workaround for the fact that HTML is was designed as a one-way method of comunication - static content.
But this is just a lack of optimization on the part of the browsers... It'll come in time. But it is not an "atrocity" like the GP was saying...
Write boring code, not shiny code!
So it appears someone's core complaint about AJAX is that a lot of AJAX sites are run on mistuned servers whose default keep-alive time is too short for AJAX. If the problem is with the TCP keep-alive mechanism, wouldn't a connection-oriented protocol have exactly the same problem?
Mozilla-Foundation failed again: (sorry, in German) http://www.heise.de/newsticker/meldung/Update-auf-Firefox-7-verschoben-1351616.html There are also desperate cries for a fork: http://in-other-news.com/2011/The_problem_with_Firefox_and_how_it_could_be_fixed
So do the sensible thing and have several native implementations.
Ideally, these native implementations should be able to share the same application logic, just with a different front-end per platform. This way, if I fix a defect in the application logic, it's fixed across all ports. This is one advantage of separating model and view layers. But apart from JavaScript in a web browser, is there a single programming language that can be used on Windows, Mac OS X, desktop Linux, iOS, Android, WebOS, ChromeOS, BlackBerry OS, and Windows Phone 7, in which to write this application logic?
Nope, pretty much all board game apps require Java, many bank websites, etc require this. I'm not saying they should, just saying they do.
That may change in the near future. In my area, applets are often used for simple chemical structure editors, but there are some commercial and free/open-source javascript solutions for this. Even 3D molecular viewers, like twirlymol:
http://baoilleach.blogspot.com/2009/01/twistymol-is-dead-long-live-twirlymol.html
There are many advantages, such as better page integration, no startup time, no "install java" popup, etc.
Today's computing ecosystem is still to volatile to guarantee perfect security whether you build from the ground up or apply endless patches and updates. Look at the number of permutations of Operating Systems, OS Versions, OS Security Patch Levels, OS Bug Patch Levels,Hardware platforms, and custom Applications. It's amazing anything works or is even half way secure especially when you introduce user actions into the mix.
No. The parent poster raises a nice point regarding TCP sockets and how they're handled to provide "instant" UI response. Google does it beautifuly but it requires a crapload of work and testing in order to get it right, not to mention it basically (again!) abuses a TCP feature intended for a completely different thing.
The problem is NOT java, the problem is SSL/TLS. Java was just the vector which was used to exploit this, and disabling Java doesn't disable the real problem, especially since Mozilla refuses to support TLS 1.1.
Its also unclear in the press how the Java same origin bypass worked for this test: Was it click to install or a real flaw? As a tool author (Netalyzr [berkeley.edu]), being able to bypass same origin without a signature dialog would be a big deal in improving the quality of our tool.
Test your net with Netalyzr
But there are simple solutions for that problem. The fact that Chrome abuses some TCP feature is a Chrome problem, not an AJAX one. Nothing prevents a browser to set a keep alive in the HTTP headers and let a socket open to the server. This is an existing feature of HTTP, respect perfectly TCP, and was even designed for that very purpose !
I have to say I'm not familiar with that specific subject, but I fail to see a problem there.
Write boring code, not shiny code!
The reaction to XUL pages on the web was horrible, "just drop support". I hope they bring it back and warn the user about the dangers on a site by site basis with both instead of dropping support.
Having to work for a living is the root of all evil.
Not to mention the original poster wasn't talking about that at all. He finally answered and his grudge is against HTML and JavaScript... ;-)
Write boring code, not shiny code!
The difference is that even though people complain about a lack of compatibility between the browsers, the differences are in fact very minor when compared to the differences between operating systems.
The main concern are old browsers, they are a nuisance. Modern browsers behave surprisingly alike.
Pretty good is actually pretty bad.
It all depends how you use AJAX I guess.
I use it to submit forms, so that I avoid the problem of having to refresh a page in which a user has made some input. In this regard, I save time and energy, and the user has a faster response. It's all a win.
I also use it to refresh some components in html pages. No DOM is needed there as it is as easily done by grabbing an HTML fragment from the AJAX request and putting wherever you need with the innerHTML attribute. Again, it saves bandwidth and time to code. Another win.
AJAX is a powerful tool that may need some tooling for some. Interpreting a JSON response is a one liner for example. No kludge in there. Manipulating the DOM is something very powerful too, but again it may need some tooling for some.
All in all, yes, browsers were once made to display static content. That was before DOM-based browsers. Things have changed.
Write boring code, not shiny code!
This applies to firefox, IE, chrome and every other browser. The exploit they're talking about attacks SSL not the browser, The java required is javascript, not a full blown java applet. The hacker would of course have to intercept your traffic, so a backdoor kind of spyware / malware program is required, or a virus, but the whole point is https just got a lot less safe, especially on infected computers.
Ooh. For an impressive commercial option, consider 3D zeolites with WebGL :
http://web.chemdoodle.com/demos/iza-zeolite-explorer
(May require ffx or chrome, doesn't load in safari)
The feature is abused by AJAX which depends on long TCP sessions. I mentioned Google because its online apps usually implement this very well (from the UI point of view, at least).
So the solution to Nintendo pissing over homebrew developers is turn every single game into web apps?
I hate JS :), but that is beyond the point. Do you realize the amount of work and back-and-forths you need to do only to perform an action when you click on something on a page?
So, I propose a solution to the bank robbing problem. Let's seal all the doors and windows of every bank with 3" steal.
Alternatively, we can remove all banks.
See...problem solved.
Exactly - this is was i was talking about. A true full-duplex web protocol would be a godsend. Thanks!
It was the accepted workaround back in the days of WiiCade before the Twilight Hack appeared.
The bad part about this entire debacle is that this exploit has been a theory for something like 6 years and no one saw fit to fix the problem. Now suddenly blame is getting aimed at people who are not at fault. The real fix for this whole thing is to update and use TLS 1.1 or 1.2 yet everyone kept whining about the expense to do that and suddenly here we are. Its too expensive to fix things the correct way since we wasted 6 years of potential amortization of the expense so everyone is scrambling to patch something that isn't even their responsibility in the first place. In the meantime we the end users are the ones being screwed over, its our PayPal and bank credentials at risk. It may not be legally sound but I honestly feel the server owners that have failed to upgrade should be subject to liability and lawsuits for allowing potentially damaging activities and code that were known to continue to function.
My home PC runs without Java for 5 or 6 years now. On office PC, Java in browser is disabled.
The biggest problem I have encountered in all the years are the error messages with freshly installed OO.o/LibreOffice starts. (But I heard LO is fixing that.)
All hope abandon ye who enter here.
you should be looking for Lindsey_Lohan_nude.jpg.exe, that's why you're not finding it
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Or I can keep the application logic on my own damn box and have you access it via a web front end. Single Model and Controller, and maybe just a couple of Views (due to mobile browser limitations).
For the average application and the average user, web-style apps are going to be the only thing that makes sense going forward. Not talking CAD here, but 99% of the other applications people use on a daily basis.
The idea of ever running an actual mail client again, for instance, is a completely alien concept to me.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
Microsoft wanted to kill java back in the 90's and the only way they could do it was with FUD. This is the biggest reason Java got such a bad rap. Looks like most of you were too young to remember though.
" Sun said Microsoft was trying to undermine the credibility of the
Java language by presenting a crippled brand of Java applications that
run only on the Windows platform. "
http://www.ibiblio.org/pjones/jomc191-97/talk/msg00064.html
boycott slashdot February 10th - 17th check out: altSlashdot.org
nobody cares what firefox and mozilla guys think anymore. these are the fuckers who took the most awesome browser in existence and ruined it into something worse than ie.
Wealth is the gift that keeps on giving.
We only leave it on machines that MUST access websites which are require an applet or a Java executable to run.
DOM based browsers still display static content :) They just make it easy for you to modify content afterwards its been served.
Someone below mentioned websockets - check it for a good overview of a proper full-duplex protocol which would solve most of these issues i've been mentioning.
As you mentioned Chrome makes all uncommon plugins click to play by default (you can even see an explicit note about this on the Java website.
For what it's worth Chrome has a general click to play feature but you need to enable it in chrome://flags/ , restart and then enable the newly available option in the general plugin preferences.
I have been using noscript http://noscript.net/ for years. Paste from thier page,
----------------------
The NoScript Firefox extension provides extra protection for Firefox, Seamonkey and other mozilla-based browsers: this free, open source add-on allows JavaScript, Java and Flash and other plugins to be executed only by trusted web sites of your choice (e.g. your online bank), and provides the most powerful Anti-XSS protection available in a browser.
NoScript's unique whitelist based pre-emptive script blocking approach prevents exploitation of security vulnerabilities (known and even not known yet!) with no loss of functionality...
You can enable JavaScript, Java and plugin execution for sites you trust with a simple left-click on the NoScript status bar icon (look at the picture), or using the contextual menu, for easier operation in popup statusbar-less windows.
----------------------
I have always thought that a white list approach was the best for anything as powerful as java & javascript, either one is essentially running someone else's unknown programs on your machine there may be a "sandbox" now but I really don't know how secure that is either
The trouble with that is that a lot of hardware manufacturers will void the hardware warranty if the owner opens the case even if the owner subsequently sets the jumper back to how it was.
Sigh ... I wondered when the Java plugin was finally going to poop out on us design-wise. Darn thing is so creaky and stuck in web 1.0-mode. Maybe it's time to port CardMeeting to HTML5...
About two and a half years ago, my home PC got rooted by a drive-by exploit that took advantage of a Java security hole. After wiping and rebuilding, I didn't install the Java plugin. Guess what? In those two and a half years, I never once have come across a site that really needs it. One site I occasionally read has animated buttons that are supposed to use Java, but not having the plugin just means that you see the alt text instead. And that's one single site. 99.9% of the time, not having the Java plugin means nothing changes.
The average user should not have Java installed.
...an eager IBM official responded with one word: "Rofl."
Doesn't everyone use QuickJava? Allows you to quickly enable/disable the java plugin from the add-on bar.
In Opera it works this way for all plugins including flash. It's not inconvenient, in fact it's very comfortable that I don't have to mess around with adblocking anymore. I whitelisted sites like youtube that require flash extensively and some of the rare sites that would break otherwise, and then it works like a charm.
Hmm, can you give a link to the source code? Afaik we don't have source code to the sun java plugin. Openjdk's java plugin is a completely different project and does not work on many sites that are only tested with sun java.
I'd say that the license would only allow you access to the Internet. Without it, you wouldn't have access. You'd still be free to do as you please except that you couldn't go online.
Which would hurt PBSKids.org, NickJr.com, and other web sites targeted to children who are too young to operate a motor vehicle.
Do you realize the amount of work and back-and-forths you need to do only to perform an action when you click on something on a page?
Good morning and yes. What's your point, that it's simpler to do it without? It's not set in stone that you need to do it this way, it's merely another option with pros and cons. Alternatively you may use a traditional POST. The caveat is the entire page is reloaded which is often unnecessary, one often only needs to update specific information on the page like an image or a text field. This is more of an architectural issue. If you want a pre-2000s website you may stick with the POSTs however a great many people tend to like the interactivity which JS provides on top of HTML - look at the popularity of Google's web offerings.
Do you realize the amount of work spent cross browser testing (and the back and forths with CSS)? Or do you know how much back-and-forth is required with traditional desktop development? For example look how much cruft is involved handling windows messages when creating a Windows application for say an OpenGL project.
Man blir trött av att gå och göra ingenting.
I bought a hard drive from Seagate with a five-year warranty. It's year two and I've been through four drives.
At least you have drives. If the warranty were voided, you'd have to spend money on a replacement now instead of later.
What's the point of a hard drive that doesn't retain data?
As half of a pair in RAID 1 or RAID 10.
I do not see any difference, from security standpoint, between a browser based application and a "native" application. Both of them have to be downloaded from somewhere, and executed on the local computer. The only difference is that browser based applications are easier to download and run, so it is more likely that a moron will run a malicious program if it is browser based.
AccountKiller
This is more of an architectural issue....
Which is exactly my point, and the point of the grandparent poster. HTML is, today, a kludge of patches over a technology that was originally built for a very different purpose. Again, someone mentioned websockets, which is (luckily) a right step torwards a modern, redesigned web protocol.
It's not really that much work. Just assign an event to the clicking of the something, make it do an Ajax-request to something on your server, let the server process the input, have it send back some output and then use that output to change something on your page. I fail to see how this is significantly more work than to do the exact same thing without Ajax.
Pretty good is actually pretty bad.
Web browsers are good for viewing static documents, especially ones that link to other static documents.
That battle was lost a decade ago. Web apps are here, and not going anywhere.
"First they came for the slanderers and i said nothing."
In my opinion, "consumer" Java should update itself automatically and quietly in the background, as Chrome does. Enterprise users that, for some reason, rely on a specific release of the JRE, will most probably want to have Java's self-update feature disabled anyway.
They also wrote that they could have used Javascript as well, and even call for a Javascript version.
According to the Mozilla bug report, this problem actually is Java - specifically, the Java implementation of TLS. NSS, the TLS library used by Firefox and Chrome, has already been patched by Google engineers. The question is whether Firefox should block Java applets to protect users, or continue allowing Java applets, in which case Firefox users can still be exploited until Oracle comes out with a fix for Java.
Well, Oracle reacting quickly to this sort of thing is about as likely as five useful Java applications being able to co-exist peacefully on a user desktop.
I mean, sure, it's theoretically possible.
There are a million different ways to get a browser to issue a known plaintext request to a server. I understand javascript is needed for this specific implementation however what is to prevent a different implementation from using an image tag, css, redirect headers, media objects..etc to issue the same request? Why is javascript required?
I had exactly 5 running Java applications 2 minutes ago, but since then I closed one after I won that chess match.
OK, one is not an application but an Apache Tomcat server I use for development.
Mozilla is working on a short-term patch to TLS that will prevent the attack in the browser (see the bug), and in the longer term will implement TLS 1.2 (but if you don't prevent TLS downgrades you haven't fixed anything, and if you do you break all the version-intolerant servers out there).
No browser fix can prevent this attack from using a vulnerable plugin such as Java since Java is making these network requests on its own. Either the plugin vendor issues a fix, or you fix it by disabling the plugin.
Well I never trusted e-mail for anything important, anyway. :)
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
"Not only is UNIX dead, it's starting to smell really bad." - Rob Pike circa 1991
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter