We’ve decided to disable support for WebSockets in Firefox 4, starting with beta 8 due to a protocol-level security issue. Beta 7 included support for the -76 version of the protocol, the same version that’s included with Chrome and Safari.
Adam Barth recently demonstrated some serious attacks against the protocol that could be used by an attacker to poison caches that sit in between the browser and the Internet.
Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox, even a minor update release. The code will remain in the tree to facilitate development, but will only be activated when a developer sets a hidden preference in Firefox.
A note for web developers: When a user doesn’t have WebSockets enabled, the WebSocket property will not be on the window object. So object detection should work.
To be clear, we’re still excited about what WebSockets offers and we’re working hard with the IETF on a new WebSocket protocol.
Pingback: disabling websockets for firefox 4Christopher Blizzard | 9nd.pl
Do we anticipate other vendors will disable as well?
Pingback: Quora
If I understand the vulnerability correctly, it only applies to transparent proxies (which shouldn’t exist) that have broken handling of HTTP (making them not “transparent”, another reason for them to not exist).
A real proxy properly configured on the end-user’s system would not have this problem, right? And, a non-broken transparent proxy wouldn’t have this problem either?
Pingback: Firefox 4 ohne Websockets « Browser Fuchs
does that affect Flash workarounds used to emulate websocket in the other browsers ?
Pingback: Quora
Given that half the applications/libraries using WebSockets use the web-socket-js Flash fallback if the browser doesn’t have window.WebSocket, disabling native support in the browser will just mean that web-socket-js is used.
Chris, does the flash security policy request mitigate this issue? If not, disabling native WebSockets probably won’t help that much in practice.
Pingback: Firefox 4 bez obsługi WebSockets | JSNews
Hope the websocket could be turn back on before FF4 is released in production.
Asa, I don’t know if other vendors will follow suit. That’s up to them. There’s a hint that Apple might, based on a comment from an Apple developer, but they don’t pre-announce things like this.
Regarding the transparent vs. not – it doesn’t matter if it’s broken proxies or not. We have to mitigate the risk of operating on the web which is filled with messy and broken stuff. And the fact that it’s a cache proxy issue means that it doesn’t just affect one person, but can affect everyone behind that proxy. That can mean anywhere from dozens to millions of people, depending on the proxy. So it would be inappropriate of us to leave this issue as someone else’s problem to fix. We’re interested in being part of the solution, not assigning blame.
Note the flash issue, which still exists. This is also a problem in flash, and I’m not sure if or what Adobe will do about it. (The vulnerability was actually demonstrated in Flash, but also may affect the in-browser websocket implementations. But the risk is high enough where we are disabling it.) Same as the other vendors – it’s up to them to decide what they want to do on behalf of their users. And, I guess, what risk they will be willing to expose other users of other browsers to as well, since if affects proxies.
I didn’t intend my comment as an assignment of blame, at least not in the sense I think you mean. I just meant, it sounds like this issue only occurs for proxies which both attempt to provide transparency and fail to actually support HTTP transparently. That seems like one of the key dangers of building a transparent proxy: screwing it up and breaking HTTP. I think a security bug exists here, but I don’t understand how the security bug exists in the *browser* rather than the *proxy*. For example, anyone else behind the same proxy could maliciously do the same cache-poisoning without the help of Firefox. Any other random malware on a single system could do the same. So, that security bug in the proxies needs fixing regardless.
“anyone else behind the same proxy could maliciously do the same cache-poisoning without the help of Firefox.”
yep, but with a Firefox WS implementation an attacker on the outside of the proxy could do the cache poisoning too. That’s bad.
And its true the same attack can be carried out with java or flash. Perhaps that will favor WS in implementors design choices when we have a relatively secure version to ship.
Pingback: Why is WebSocket support being removed from Firefox 4? - Quora
FTR, Opera decided to disable Websockets as well:
http://annevankesteren.nl/2010/12/websocket-protocol-vulnerability
Why not only disable WS for non-ssl based connection? Aren’t they unaffected and in fact work through proxies in the same way that the new proposed handshake does?
I implemented the actual protocol for php with the auth thing.
The problem in the protocol is, at the handshaking the server must answer a challenge from the client, but only at the handshake process.
However I wondered why only the server has to solve a challenge, cause mostly the client will be untrusty.
Currently I have no real suggestion how to modify the protocol too make sure only the client from the handshake is accepted and communicating. Possibly the Protocol can specify a key exchange at the handshake and encrypt the protocol with this key.
Don’t know if this would already do it.
Pingback: WebSockets disabled in Firefox 4
Pingback: WebSockets disabled in Firefox 4
What a disappointing decision. Why is everyone being held back because a few proxies are broken?
Pingback: Web Sockets shows Web standards travails | Technology News
Pingback: Web Sockets and the risks of unfinished standards | Hope and feel
Pingback: The Cheap Computer Geek » Blog Archive » Web Sockets and the risks of unfinished standards
Pingback: Web Sockets and the risks of unfinished standards Truman Consulting Group - Tekpedia.Net - Truman Consulting Group
Pingback: Mozilla and Opera Disable Web Sockets In Their Browsers Due To Vulnerabilities in the Protocol | Product Sourcing - Industrial News
Pingback: Web Sockets and the risks of unfinished standards Frugal Tek - Technology On A Budget - Frugal Tek
hmm, why not leave it on for SSL?
Pingback: Web Sockets and the risks of unfinished standards « Mohinder's Blog
Pingback: Web Sockets and the risks of unfinished standards | Games 4 Downloading
Pingback: Revision 7: Dateisystem, Android 2.3, Websockets-Protokoll-Glitch, CSS 2.1 | Working Draft
Pingback: Working Draft Revision 7: Alles doof • Peter Kröner, Webdesigner & Frontendentwickler
Pingback: Tune Up Your PC » Post Topic » HTML5, Site-Ready and Experimental
Pingback: Windows 7 Insider » Blog Archive » HTML5, Site-Ready and Experimental
Pingback: HTML5, Site-Ready and Experimental
Pingback: Desde las entrañas de Microsoft: Cómo IE9 implementará HTML5 | RedUSERS
Pingback: Firefox 6 chega ao canal Aurora « abilitytec
i use firefox 6 now.:D
Pingback: Developing with Browser- and Feature-Detection » SitePoint
Pingback: Hack all the world - BEAST Attack - Focusecurity.Org
Pingback: Browser and Feature Detection: Make your Website look Great Everywhere
Pingback: Vemos como no todo es HTML5 y los principales cambios que incorpora. « Comentario Geek