Mozilla Hacks

WebSocket disabled in Firefox 4

By Chris Heilmann

Posted on December 8, 2010 in Firefox, Security, and WebSocket

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.

About Chris Heilmann

Evangelist for HTML5 and open web. Let's fix this!

More articles by Chris Heilmann…

47 comments

  1. Matt Ranney

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

    December 8th, 2010 at 18:00

    1. John Haugeland

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

      Security is not the place for guesswork.

      December 8th, 2010 at 19:19

    2. WulfTheSaxon

      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).

      December 9th, 2010 at 00:20

      1. Henri Sivonen

        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.

        December 9th, 2010 at 02:47

        1. Billy

          >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

          December 16th, 2010 at 14:29

  2. Sasha Aickin

    Arguably, this is

    December 8th, 2010 at 21:38

  3. Sasha Aickin

    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.

    December 8th, 2010 at 21:41

  4. Kyle K

    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??

    December 8th, 2010 at 21:54

    1. Unni V Mana

      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).

      January 3rd, 2011 at 22:30

  5. Marco Pivetta

    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! :)

    December 9th, 2010 at 01:08

  6. wdu

    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 :-)

    December 9th, 2010 at 02:42

  7. Ruud Poutsma

    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.

    December 9th, 2010 at 03:17

    1. lapc506

      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?

      January 8th, 2011 at 10:04

      1. Montana

        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.

        February 7th, 2011 at 07:06

      2. Michael C.

        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).

        June 22nd, 2011 at 19:16

  8. hmmm

    not cool man

    December 9th, 2010 at 03:25

  9. Danny Moules

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

    December 9th, 2010 at 06:17

  10. Mark Roggenkamp

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

    December 9th, 2010 at 06:39

  11. Daniel Ennis

    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.

    December 9th, 2010 at 07:19

  12. Martyn Loughran

    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

    December 9th, 2010 at 08:09

  13. Jon Neal

    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…

    December 9th, 2010 at 08:23

  14. qwe

    Are you serious?

    December 9th, 2010 at 14:04

  15. dss

    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?

    December 9th, 2010 at 14:59

  16. Yuri Agenni

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

    December 9th, 2010 at 17:16

  17. ben porter

    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..

    December 9th, 2010 at 18:33

  18. MRK

    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

    December 10th, 2010 at 08:35

  19. Ruhsen Kahraman

    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.

    December 11th, 2010 at 03:09

  20. jonathan Chetwynd

    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?

    December 12th, 2010 at 14:29

  21. Olav Kolbu

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

    December 14th, 2010 at 07:01

  22. TJ Vanderpoel

    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.

    January 11th, 2011 at 13:52

  23. WulfTheSaxon

    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.)

    January 11th, 2011 at 16:25

  24. James B

    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.

    January 23rd, 2011 at 12:38

    1. James B

      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.

      January 23rd, 2011 at 12:40

  25. Quizori

    At least. I need 127.0.0.1 is allowed.

    February 21st, 2011 at 03:07

  26. the future

    Huge mistake.

    I hope for a fix ASAP….

    February 28th, 2011 at 16:55

  27. Zequez

    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

    March 23rd, 2011 at 19:24

  28. whatdoesitwant

    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.

    March 30th, 2011 at 12:00

  29. WulfTheSaxon

    @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.

    March 31st, 2011 at 08:36

  30. whatdoesitwant

    @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.

    April 1st, 2011 at 07:30

    1. Aikar

      @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.

      April 1st, 2011 at 15:30

  31. mc

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

    April 19th, 2011 at 14:29

  32. DAlDo

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

    April 23rd, 2011 at 15:35

  33. Kristjan

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

    May 10th, 2011 at 06:22

  34. José Angel Yánez

    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…

    June 13th, 2011 at 16:50

  35. viktor

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

    July 1st, 2011 at 04:52

  36. Tom

    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.

    August 20th, 2011 at 11:41

  37. saga

    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.

    August 31st, 2011 at 14:42

Comments are closed for this article.