Mozilla

WebSocket disabled in Firefox 4

Recent discoveries found that the protocol that Websocket works with is vulnerable to attacks. Adam Barth 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.

This is a serious threat to the Internet and Websocket and not a browser specific issue. The protocol vulnerabilities also affect Java and Flash solutions. In a web environment that could for example mean that a widely used JavaScript file – like Google analytics – could be replaced on a cache you go through with a malware file. Google would not be to blame and it would be hard for you to trace where the file is from as it will not be on your server. To avoid a lot of malware showing up without being easily traceable we need to fix the protocol.

No Websocket support in Firefox 4 and Opera until the security issues are fixed

That’s why we’ve decided to disable support for WebSocket in Firefox 4, starting with beta 8 due to a protocol-level security issue. Beta 7 of Firefox has support for the -76 version of the protocol, the same version that’s included with Chrome and Safari. Beta 8 of Firefox 4 will remove that support. Anne van Kesteren of Opera also announced that Opera are dropping Websocket support. We are confident that other browser developers will follow.

What does this mean for developers?

Right now, your Websocket solutions will not work in Firefox 4 final. 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 help development, but will only be activated when a developer sets a hidden preference in Firefox (the same applies to Opera).

If your code does proper object detection nothing should go wrong – when a user doesn’t have Websocket enabled the window.WebSocket property will not be available.

Working on a fix

Mozilla is still excited about what WebSocket offers and we’re working hard with the IETF on a new WebSocket protocol.

Right now we are pushing the boundaries of what browsers can do for their users – this is what HTML5 is about.

Whenever you push the boundaries of any technology you will run into issues. The great thing about our situation right now is that we can react quickly and swiftly to any issues arising and fix them before our end users are the ones who suffer. Making the whole world upgrade and patch a final browser is almost impossible which is why it makes sense to test and patch in betas and nightlies.

47 comments

Comments are now closed.

  1. Matt Ranney wrote on December 8th, 2010 at 6:00 pm:

    This sounds like a pretty serious issue. Shouldn’t you also disable Java and Flash as well?

    1. John Haugeland wrote on December 8th, 2010 at 7:19 pm:

      No. Flash and Java, having been well designed, do not suffer this attack.

      Security is not the place for guesswork.

    2. WulfTheSaxon wrote on December 9th, 2010 at 12:20 am:

      I believe what was meant was that a Flash or Java implementation of WebSockets would be vulnerable, as it’s a vulnerability in the spec itself, not any one implementation (like CSS history sniffing or the recent JavaScript exploit).

      1. Henri Sivonen wrote on December 9th, 2010 at 2:47 am:

        According to the paper, the attack against vulnerable transparent proxies can be mounted from Java and Flash applets regardless of the existence of Web Socket.

        It will be interesting to see how Adobe and Oracle on one hand and vendors of transparent proxies on the other respond to the findings presented in the paper.

        Note that if you are behind a vulnerable transparent proxy and someone else behind the same proxy runs software that can be used to poison the cache of the proxy, you are vulnerable to getting bogus data from the poisoned cache (as I understand the paper). Thus, the best defense is to use an ISP that doesn’t force a transparent proxy on you.

        1. Billy wrote on December 16th, 2010 at 2:29 pm:

          >Thus, the best defense is to use an ISP that doesn’t force a transparent proxy on you.

          Uh, yeah, thanks, that’s a great solution.

          - Your ISP doesn’t even tell you if it uses one
          - Your ISP probably won’t answer you if you ask
          - Consumers don’t have free choice because of ISP monopolies like Comcast. If you want cable internet in my area, they’re the only game in town, and they actively work to fight against free choice

          That’s not reasonable, to say that someone should change to slow and high-latency satellite internet or impossible DSL (can’t use it if you’re too far away or you have an alarm system or there’s too much crackle on your line or the planets aren’t aligned just right that day) just because of some particular security vulnerability normal people haven’t heard of, nor would they understand if they did

  2. Sasha Aickin wrote on December 8th, 2010 at 9:38 pm:

    Arguably, this is

  3. Sasha Aickin wrote on December 8th, 2010 at 9:41 pm:

    Arguably, this is a vulnerability not in the WebSocket protocol, but in transparent proxy implementations, no?

    Also, Matt makes a great point. If you are disabling WebSockets for this reason, why wouldn’t you also disable Flash and Java, both in FF4 and in the shipping FF? They are as vulnerable as WebSockets, it seems.

  4. Kyle K wrote on December 8th, 2010 at 9:54 pm:

    Please correct me if I’m misunderstanding the attack vectors, but this has nothing to do with a vulnerability in WebSockets and everything to do with transparent proxies and target systems that blindly trust data flowing across them.

    Attack scenario:

    1) Browser visits malicious.com through a proxy

    2) malicious.com returns an SWF

    3) Browser runs the SWF and retrieves a policy file from malicious.com that says you can open a socket to anywhere

    4) Browser allows SWF to open a socket to malicious.com through the proxy targeting the same URL and port as the original HTTP request.

    5) SWF sends bytes to malicious.com which pass through the proxy and the bytes happen to be valid (but forged) HTTP. The forged HTTP has a HOST header of target.com

    6) Proxy reads the bytes and blindly routes the forged HTTP request to target.com, requesting “secret” data.

    FAIL the proxy doesn’t validate that the forged HOST of target.com matches the originally requested HOST of malicious.com that caused the (kept alive and now re-used???) socket to be opened in the first place, still assuming that it’s being used for HTTP and not some other protocol.

    FAIL the proxy does nothing to validate that the URLs in the HOST headers resolve via DNS to consistent IP addresses.

    7) target.com receives an HTTP request for a “secret” document from the proxy server and replies to the proxy with the data, which is then sent back to the browser and subsequently becomes available to malicious.com’s SWF

    FAIL target.com assumes that an HTTP request with a HOST header of target.com from a proxy is authentic without checking against a session cookie or password to determine authentication and authorization.

    How is this the fault of Java, Flash, or WebSockets?

    Attack scenario:

    1) Visit malicious.com, receive script that submits a POST to malicious.com that actually requests a WebSocket upgrade

    2) Proxy ignores WebSocket Upgrade request, but passes response back from malicious.com, thus keeping the socket connection alive

    3) Browser sends bytes over WebSocket to proxy that are forged (but valid) HTTP targetting HOST target.com and requesting some popular javascript file

    4) Proxy doesn’t know about WebSockets, thinks it’s just another HTTP request, and so passes the request to malicious.com (despite HOST header specifying target.com)

    5) malicious.com responds with nasty javascript code

    6) Proxy assumes the response is from HOST target.com and NOT malicious.com (huh?! see step 4), and stores nasty javascript code in its cache for target.com

    7) Nasty javascript code gets served to anyone else requesting that resource from target.com through that proxy

    FAIL what the heck…?? Beyond words

    Again…this is the fault of WebSockets??

    1. Unni V Mana wrote on January 3rd, 2011 at 10:30 pm:

      Kyle, I agree with you.This is not the problem of WebSocket.Because FF had seen this issue and work on to overcome the vulnerable aspect of this kind of environement so that in any worse environment websocket implementation should not be affected.Had there been issue, then the issue is arised becaiuse of TCP because it allows socket connection and websocket directly works over TCP(as per websocket spec).

  5. Marco Pivetta wrote on December 9th, 2010 at 1:08 am:

    This is soo sad :(
    I’ve been waiting for WebSockets for a while, and now every project of mine using them will have to stop or move to http polling or similar “dirty” solutions…
    I hope that Mozilla and the IETF can get the new spec ready as soon as possible: WebSockets are one of the most important changes in web development, as it could allow any kind of application to run on a browser (In my case FPS games and games in general)…

    Thumbs up guys, keep on with the good work! :)

  6. wdu wrote on December 9th, 2010 at 2:42 am:

    How exactly will this address the security problem described in the paper? Those buggy proxies are buggy and will remain vulnerable, no matter what mozilla does.

    You could as well stop all new releases of mozilla. That won’t fix the problem neither :-)

  7. Ruud Poutsma wrote on December 9th, 2010 at 3:17 am:

    Can there please b a possibility to have it *off* by default for every website, but turned *on* optionally for trusted sites?
    This way we can still roll it out, but keep the web as (un)safe as it is.

    1. lapc506 wrote on January 8th, 2011 at 10:04 am:

      But then, it can be a security hole on which a stolen certificate from a secure trusted site i.e. Google (the one Google uses in HTTPS for Gmail) can be used to “turn on the pref”, FF thinks it’s secure, the altered certificate gives access to “nasty code” from an malicious site through WebSocket while you think you are still using HTTPS. If the altered certificate includes special code in JavaScript that says “Keep open WebSocket” (even when closed, and FF saves this pref) this should be a big problem, ¿isn’t it?

      1. Montana wrote on February 7th, 2011 at 7:06 am:

        Better yet, why doesn’t Firefox let us decide whether or not we want WebSockets enabled?

        Oh and here’s an idea: Why not create a public-key system for security certificates? Then FF could possibly detect a stolen certificate.

      2. Michael C. wrote on June 22nd, 2011 at 7:16 pm:

        Your entire scenario is botched to begin with because that’s not how certificates work at all. You’d not only need the cert (anyone can get the cert from any site since it’s public) but also, and most importantly, the cert’s private key. Secondly, you could only serve the cert from the domain name (or sub-domain) specified in the cert, so you’d also have to perform DNS poisoning. Thirdly, you can’t include Javascript code inside a cert (or, even if you could via some ancillary extension, it would be meaningless).

  8. hmmm wrote on December 9th, 2010 at 3:25 am:

    not cool man

  9. Danny Moules wrote on December 9th, 2010 at 6:17 am:

    A terrible shame but the swift response is greatly appreciated on the ground!

  10. Mark Roggenkamp wrote on December 9th, 2010 at 6:39 am:

    Why not leave WS over SSL/TLS. Don’t they already essentially use the same mechanism to pass through proxies as is being proposed?

  11. Daniel Ennis wrote on December 9th, 2010 at 7:19 am:

    Guys…

    This is the wrong move. I really hope Mozilla reviews this decision immediately and reverts it.

    Read the PDF!!! The vulnerability does NOT lie in WebSocket, Java OR Flash.

    The vulnerability is in the proxy servers themselves.

    ANY language or platform that can open a socket connection can abuse the vulnerability in some proxy servers.

    What it boils down to is that the handshake of WebSocket connections confuses insecure proxy servers. This is no fault at all on the websocket spec.

    To say it is, is to say ANYTHING that has a spec that looks like HTTP is “vulnerable” which is very incorrect to say.

    The bug lies in proxy servers, and closing off websockets does _NOTHING_ to fix said vulnerability but just closes off 1 possible implementation.

    I fully support the idea of changing the handshake to use the CONNECT method to alleviate websocket being used, but removing websocket support is the most horrible idea as its not websockets fault.

    Please Mozilla, reconsider this and turn WebSockets back on but continue to push for changing the spec to use CONNECT.

    Removing support for a standard just because it can be used to exploit a vulnerability in another software is a very poor decision.

    Under that logic, we should remove ajax because some http servers can be exploited, or remove javascript support because some plugins can be exploited.

    It doesn’t make sense.

    Please, revert this decision ASAP. It’s a horrible mistake.

  12. Martyn Loughran wrote on December 9th, 2010 at 8:09 am:

    While this is an annoying setback, it is worth putting it in perspective by pointing out that this should hopefully be temporary. It is not a fundamental flaw in the WebSocket concept, merely an issue exposed by the current __draft__ specification.

    What’s more, the issue is about broken proxies that can already be exploited from Flash and Java, and also theoretically by the current WebSockets draft.

    As a company that provides WebSockets as a service, we remain confident that they will go on to become a very core part of people’s everyday online experience. I wrote more about our thoughts in this blog post:

    http://blog.pusherapp.com/2010/12/9/it-s-not-websockets-it-s-your-broken-proxy

  13. Jon Neal wrote on December 9th, 2010 at 8:23 am:

    Wasn’t Douglas Crockford warning about serious security vulnerabilities in HTML5 a year ago? I would have to think this is one of the things he was talking about…

  14. qwe wrote on December 9th, 2010 at 2:04 pm:

    Are you serious?

  15. dss wrote on December 9th, 2010 at 2:59 pm:

    It looks like these people at firefox and opera teams are totally insane…
    This attack is against broken proxies, not against websockets.
    Websockets themselves are safe.
    How websockets are related to the way proxies handle http upgrade?
    Even if you totally disable websockets all over the world, everyone can mount this attack against your proxy, just by sending malformed http request to it.
    How this prohibition of websockets was intended to help fix all these crappy proxies?

  16. Yuri Agenni wrote on December 9th, 2010 at 5:16 pm:

    This pretty much summarized my experience of websockets in 2 minutes: http://www.xtranormal.com/watc…/

  17. ben porter wrote on December 9th, 2010 at 6:33 pm:

    Oh no, that’s not good news. My entry for gameon 2010 uses websockets.

    I hope the judging committee will allow flash xmlsockets in the comp now that websockets are out of the question..

  18. MRK wrote on December 10th, 2010 at 8:35 am:

    We are fortunate that someone in the “Web4.0″ (are we there yet?) is using their aptitude and awareness! Regardless if most folks leave cookies open and tape passwords to their monitor, any “feature” added, even if it is “disable-able” that could compromise security should not be “thrown to the masses” without asking 2 questions:

    First, how could the most malicious person use available resources to manipulate this new feature for evil?

    Second, Does this feature benefit those that expect productive, stable and secure applications, as well as satisfy the marketeers and amuse the general public.

    I am glad someone at least asked one of them. :)
    MRK

  19. Ruhsen Kahraman wrote on December 11th, 2010 at 3:09 am:

    I am using websocket in my project and working fine and wont change with another solutions. I believe developers will fix the problem. websocket will change the browsers as dead clients to smart living consoles.

  20. jonathan Chetwynd wrote on December 12th, 2010 at 2:29 pm:

    sounds more than a little disingenuous,

    what is the ‘hidden preference’ for developers?

    network.websockets.enabled remains set to true….

    so as a developer, how do I enable websockets?

  21. Olav Kolbu wrote on December 14th, 2010 at 7:01 am:

    Browse to about:config and toggle network.websocket.override-security-block

  22. TJ Vanderpoel wrote on January 11th, 2011 at 1:52 pm:

    I just wish the Opera and Mozilla developers would be honest about _where_ the vulnerability lies. It has nothing to do with websockets specifically but rather in software and devices that proxy web traffic. Has anyone named the buggy devices and software and begun the work of pressuring them to fix their weaknesses that allow the vulnerability to be exposed (by websockets, flash, java, any plugin which can do raw sockets)? That would seem a better direction than disabling websockets and breaking app support (our websockets internal callcenter stopped working as our users upgraded from FF4B7 to B8). At least this gave us the ammunition to convert from FF to chromium, not sure that’s what y’all intended by this move.

  23. WulfTheSaxon wrote on January 11th, 2011 at 4:25 pm:

    As Olav said above: “Browse to about:config and toggle network.websocket.override-security-block”. No need to switch to Chrome. (Although, frankly, you shouldn’t be using pre-release software in a business anyway.)

  24. James B wrote on January 23rd, 2011 at 12:38 pm:

    The best defense is *to not use HTTP for sockets*.
    Just give us Flash style real sockets and , that is sufficient, and if the host wants to allow HTTP requests they have to specify it. Safer *and* more versatile.

    1. James B wrote on January 23rd, 2011 at 12:40 pm:

      I tried to say policy-file-request. Turns out having it in a tag filters it out.
      In any case, policy-file-request means that Flash sockets can only be used on ports of a server specifically approved. This really is the best way.

  25. Quizori wrote on February 21st, 2011 at 3:07 am:

    At least. I need 127.0.0.1 is allowed.

  26. the future wrote on February 28th, 2011 at 4:55 pm:

    Huge mistake.

    I hope for a fix ASAP….

  27. Zequez wrote on March 23rd, 2011 at 7:24 pm:

    Awwwww =(
    Websockets are awesome =/
    Hope you find out how to implement it securely soon ^^
    Anyway this won’t prevent me to keep doing awesome HTML5 experimental-apps that only I can run :P

  28. whatdoesitwant wrote on March 30th, 2011 at 12:00 pm:

    Is there a way to script websockets on and off from the command line? I need it on during development and off at other times. Some sort of shell script for windows would do. Alternatively if i could install two versions of Firefox on the same system i could limit one of these to the lan.
    The technique described at http://techdows.com/2010/12/turn-on-websockets-in-firefox-4.html is a bit of a hassle.
    I’d much appreciate any pointers.

  29. WulfTheSaxon wrote on March 31st, 2011 at 8:36 am:

    @whatdoesitwant: “firefox.exe -p” from the command line will open the profile manager, allowing you to create a new profile. Afterwards, “firefox.exe -p profileName” will open a specific profile (add -no-remote to your dev copy so it can be opened at the same time).

    No idea why there’s no shortcut to the profile manager by default in Firefox (it is in Songbird and some other XULRunner apps). I’ve had stable and nightly branches installed in different directories with their own profiles for years.

  30. whatdoesitwant wrote on April 1st, 2011 at 7:30 am:

    @Wulf Thank you, that worked. At first I created a copy of firefox.exe as firefoxdev.exe to have windows and my firewall recognize the instances as separate applications. But obviously an extra installation in a separate directory like you suggest is safer. On another note, restricting a firefox instance to the lan will of course prevent it from updating. So I use a third party program secunia psi to cater for that.

    NB I noticed that Chrome (10) is using websockets by default despite the security issue. Hopefully it will be fixed soon.

    1. Aikar wrote on April 1st, 2011 at 3:30 pm:

      @whatdoesitwant: Because chrome is smart.

      There is no security vulnerability in Web Sockets.

      the WS protocol is fine, and the implementation of it in Firefox Chrome and others are fine.

      There is ABSOLUTELY no reason for WebSockets to be disabled

      It’s sad Mozilla STILL hasn’t realized their mistake.

  31. mc wrote on April 19th, 2011 at 2:29 pm:

    So why they still didn’t turn it on? What is the future of websockets in Firefox?

  32. DAlDo wrote on April 23rd, 2011 at 3:35 pm:

    Is there any news on WHEN the websockets are to be back in FireFox? Can you please update the status of the fix?
    Thabks.

  33. Kristjan wrote on May 10th, 2011 at 6:22 am:

    Is it possible to upgrade web-socket over https? Would it still be vulnerable to proxy issue?

  34. José Angel Yánez wrote on June 13th, 2011 at 4:50 pm:

    What?

    This is aweful, it’s not a WebSockets issue, it’s a proxy issue, anyone could exploit that issue any kind of socket, let’s say:Flash.

    Kirk you’re right about it…

  35. viktor wrote on July 1st, 2011 at 4:52 am:

    That issue has already been solved, please you shouldn’t comment this anymore!

  36. Tom wrote on August 20th, 2011 at 11:41 am:

    If we’re going to take this fatalistic stance that the affected proxies are going to be with us forever, then shouldn’t we just avoid this port 80 mess altogether?

    Why not standardize a WebSockets-like protocol on a completely separate port. Port 40, say. Sure, initially many users behind draconian proxies won’t be able to use it at all, but no access is arguably better than insecure access.

    This protocol could be far simpler, because it doesn’t have to do an HTTP handshake on top of the TCP handshake, and because it doesn’t have to concern itself with backwards-compatibility.

    We could even have a complimentary UDP version of the protocol, which would make voice-over-web possible without Flash.

  37. saga wrote on August 31st, 2011 at 2:42 pm:

    It is a horrible decision and lots of projects that relies on websocket are probably get killed, think about those user who use firefox 4+ will have trouble to use this functionality.

    Also Mozilla released 3 version of firefox, 4,5,6 and this would cause sensitive client require more testing work on the web development, the development team is just bow.

Comments are closed for this article.