WebSockets Disabled by default for Firefox 4

http://cometdaily.com/2010/12/07/websockets-disconnected-for-firefox-4/

by thehodge • 16 years ago

74 58 16 years ago

Yet another reason Chrome's rolling release auto updates are glorious. (When the protocol is fixed, Chrome users will all have it within a day or two; Firefox users, not so much)

Additionally: Nochum's comment is concerning, if accurate:

>This is gonna suck since the feature detection will be totally thrown off.

>E.g.:

>if (WebSocket in window) > ...

axod3• 16 years ago

Relying on feature detection alone for WebSocket is a big mistake though. Websocket can fail for a number of reasons - proxies, stupid ISPs that interfere with HTTP traffic etc.

In Mibbit, the code is something like this:

  if(WebSocket in window) {
    tryWebsocket();
    window.setTimeout(function() {
      if (nothingHappened()) useComet()
    }, 5*1000);
  } else {
    useComet();
  }

Where comet in this case is keep alive long polling XHR.

taitems• 16 years ago

That's an interesting way of managing timeouts. Is the 5*1000 intended to just be a more readable way of specifying seconds?

catechu• 16 years ago

How can you check if nothing happened?

bradgessler• 16 years ago

Libraries like Socket.IO will detect if the connection can be made or not... so this point is moot.

Feature detection first, connection detection second, then start degrading the transport until all options are exhausted.

ergo98• 16 years ago

Yet another reason Chrome's rolling release auto updates are glorious.

I like Chrome's silent updates, but the only real difference between it and Firefox is that Firefox informs the user that the update is being applied. Other than that, I'm not sure what you're referring to.

drivebyacct25• 16 years ago

Chrome updates much more frequently and I think you discount the amount that users ignore the update warnings.

jackvalentine• 16 years ago

Isn't Firefox 4 where Mozilla want to start using silent updates?

drivebyacct25• 16 years ago

Firefox is just playing catchup these days, isn't it? Don't get me wrong, that's fantastic. I think everyone benefits from auto-updates.

natmaster2• 16 years ago

Not true. Firefox has auto updates, and will be pushing websockets the moment it gets fixed. Firefox also has the best record for turnout time on security fixes (many being released two days after report), so I doubt that will be slow.

From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire...

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

drivebyacct25• 16 years ago

I don't know what you're calling not true. I never suggested that Firefox wouldn't fix this in a x.1 revision. My point is more than 14% of Firefox users are using a version lower than current stable (and that's not counting who is in the [3.6.0, 3.6.12) range.

roschdal• 16 years ago

Scandalous.

tieTYT• 16 years ago

This article didn't provide any more information than the title. Can anyone fill the rest of us in. What are WebSockets and why should I care?

pjscott2• 16 years ago

They're bidirectional sockets between the web browser and the server, essentially. They're handy whenever you want messages going back and forth between client and server without a bunch of reconnecting, or really ugly hacks.

For example, apps like Etherpad or Apache Wave need to send messages for each editing operation (e.g. keystrokes), and it would really suck if they had to open a new HTTP connection for each one and do long-polling to receive from the server. Websockets make this sort of thing simply a matter of sending and receiving on a socket. Easy.

You can fake them with something like Socket.IO, if you want the API and are willing to tolerate unpleasant performance on browsers that don't support it.

tjarratt2• 16 years ago

What's the alternative for browsers that don't support it? If you want to gracefully degrade, then you may have to accept an underperforming solution.

I'm using Socket.IO and while I'd rather not have to degrade to Flash for Firefox, if that's what I have to do to get support for Firefox users that haven't enabled websockets, I can live with it.

mhitza2• 16 years ago

WebSockets are ugly hacks on their own. They use HTTP as well for the underlying channel of communication.

The only difference is that with the WebSockets the ugliness is hidden from your daily programmer via a nice API.

pjscott2• 16 years ago

Damn it! WebSockets are one of the nicest things in HTML5, and even for people using a compatibility layer like the excellent socket.io, things just seem to work better when the browser supports WebSockets natively.

Of course, we're not going to get ubiquitous WebSocket support until Internet Explorer 10 becomes the new IE 6, which I doubt will happen for a long time. Even so, Firefox could make a big difference here. It would be nice.

natmaster2• 16 years ago

From: http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire...

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

kondro3• 16 years ago

I think the WebSockets movement just died a little.

It's already hard enough to write modern web-apps that work across a multitude of browsers either replicating features with crappy techniques in the older ones or being given the capability to degrade gracefully. Now, a feature that was expected on modern browsers now doesn't exist on some of them.

Yes, I understand that there are security concerns, but it was concerns like this that lead browser makers to disable cross-domain JavaScript rather than implement a solution to do it securely. I hope WebSockets doesn't end up going the same way.

Tichy• 16 years ago

Maybe there is no simple solution.

kondro3• 16 years ago

For WebSockets? Maybe there isn't. It's not really the browsers fault necessarily, W3C takes many, many years to ratify standards so they go ahead an implement things themselves causing incompatibilities and, in the case of WebSockets, for them to provide features they now have to take away again.

For cross-site scripting, there are many ways this could be enabled. Like the way Flash does it, for example, by placing a file at the root of a domain which specifies all the other domains it is allowed to talk to. Providing a manifest like this is likely the simplest solution to a problem that makes designing thick-clients quite annoying.

wmf3• 16 years ago

It's not clear that this security issue is real, but the WebSocket protocol is definitely going to change soon in a major way. I've been reading the the IETF HyBi list and the whole situation is pretty depressing.

stanleydrew• 16 years ago

Can you elaborate on that? I'm very interested in the progression of WebSocket and I wonder what's depressing you about the situation.

wmf3• 16 years ago

The last few months have been mostly occupied by arguments about hypothetical security holes — not in WebSocket itself but in other software that WebSocket might be used to exploit. During this time, virtually no actual work on the protocol seems to have been done. The recent paper (flawed as it is by ignoring framing) purporting to demonstrate such a security hole seemed to catalyze browser developers into a decision for a few days, but then the list collapsed into nitpicking and misunderstandings again.

Meanwhile all of the alternatives that are being debated in the IETF are different from the WHATWG version that is deployed in some browsers today, so even if Mozilla did ship Firefox 4 with WebSocket, that version is already obsolete; we know there will be a replacement but we don't know exactly what it will be.

tptacek3• 16 years ago

I'm not sure how one could interpret "we launched this attack using an advertising network on the general population of the Internet and found cases where connection routing fell under the control of our attacker" as "not a real issue".

I see the political concern in your followup, but you didn't actually rebut the paper. It's an EKR-endorsed protocol security paper; my bet is, they're right. The problem statement certainly makes sense (browsers and proxies, both critical to Internet security, are not evolving the HTTP protocol in lock step).

wmf3• 16 years ago

The experiments in the paper didn't use WebSocket framing which likely would have prevented the attack from working. http://www.ietf.org/mail-archive/web/hybi/current/msg04750.h...

tjarratt2• 16 years ago

I'm really curious what Mozilla's motivation is for disabling websockets over security concerns. Is it that they are susceptible to man in the middle attacks, and a websocket connection could be started with an untrusted server?

Anyone familiar with security and websockets?

edit: I'm using websockets in a few projects (gracefully degrading to flash or XHR), and I'd like to know whether I should reevaluate webSockets.

edit2: according to this mailing list, it's an issue with how proxies handle the HTTP Upgrade header. Awesome.

http://www.ietf.org/mail-archive/web/hybi/current/msg04744.h...

FooBarWidget2• 16 years ago

Details are linked right there from the article.

nitrogen2• 16 years ago

After reading eight or so e-mails from the thread you linked, it sounds like the vulnerability is in various proxies, not in WebSockets itself.

oofo• 16 years ago

Exactly the other way around, some man in the middle attacks get confused in the presence of websockets: "The Upgrade-based handshake is vulnerable to attack in network configurations involving transparent (or intercepting) proxies"

It's pretty weird that they consider this a problem with websockets.

tptacek3• 16 years ago

It's not an issue of "attributable fault". It's an issue of a reasonable protocol that doesn't work reliably on deployed infrastructure. Unlike, say, HTML5 Canvas, where failures still degrade somewhat gracefully, a failure that tickles a bug in a widely deployed proxy can be catastrophic.

Let's all be clear that the "fault" lies in crappy HTTP code deployed in middleboxes (and that includes mine), but pragmatic in understanding that that doesn't matter; browsers can't become roving exploits for proxy bugs just because a standard says so.

catshirt• 16 years ago

maybe there is a problem. this is not the solution.

another checkmark on a long list of frustration with firefox 4.

weavejester2• 16 years ago

What else can they do? If the websocket protocol is insecure, they need to wait until its fixed. They'll probably re-enable it in Firefox 4.0.1 or 4.0.2 with a fixed websocket implementation.

drdaeman2• 16 years ago

Stop spreading FUD.

Websocket protocol is perfectly fine. What's insecure are broken proxies.

jerf• 16 years ago

It still seems to me the problem is that they tried too hard to wrap the sockets into "the web". Just open a standard TCP socket to the web site's specified port and server. Layer me in some automatic SSL negotiation using the site's HTTPS cert (or something signed by it) if you want to win points. (Probably should mandate this, in fact, as it would block off most of the remaining "forging what site to connect to" issues; not unless you have the correct SSL info, in which case you've won anyhow.)

I'm not sure what proxies are doing involved in sockets at all. I do not see what useful thing you can do with a proxy, except maybe flat-out block web sockets. They can't meaningfully cache, they can't meaningfully enforce policy except with the blindest, stupidest of approaches that should probably be in another layer anyhow. There's not enough structure in a raw socket connection to do anything with, what structure is there could and should be managed by your router.

I'm sure there's some massive problem I'm missing here. (Though if it's "users can't use websockets through a proxy", frankly, I don't really see that as a problem that has a solution. By the time you fix up your "proxy" to allow "essentially arbitrary socket connections" what you've got there is a "router". If you're in an environment where you actually must use a proxy for some reason, you're in an environment that is probably going to ban arbitrary socket connections anyhow.) Now's your chance to enlighten me, I guess. I'm not trolling here, I do believe this, but I'm interested in the answers people give too. Maybe someone will convince me. (No joke.)

nitrogen2• 16 years ago

Proxies are an issue because many corporations (and even ISPs) force all web traffic through a transparent proxy by redirecting outbound traffic to port 80 (and likely 8080 and 3128). HTTP proxies have long supported a way of establishing a raw TCP connection (though I'm unsure of the details), allowing things like corkscrew for using ssh behind a corporate firewall. As far as I know, these things use HTTP CONNECT. It seems there's another approach, HTTP Upgrade (which appears to be for switching to/from encrypted mode), which is used by WebSockets but breaks many proxies to the point of vulnerability to cache poisoning.

I suppose if there are enough broken proxies out there that can't handle WebSockets, it's better not to take the blame from all those IE6 corporate types for breaking their Intranets.

jimmyjazz142• 16 years ago

Features like the "Host" header and built in support for proxies are important to the infrastructure of the web, I believe websockets are an attempt to preserve these feature among others while allowing a socket like connection. This idea seems supported by the fact that Websockets use an intial handshake over HTTP which allows the same server that handles HTTP request to handle websocket request.

adamzochowski• 16 years ago

Except for ssl the header is encrypted. so you can't use Host header on ssl proxy. This is where HTTP CONNECT comes in. Connect is a second header that tells proxy on how to proxy, and then the rest of connection is raw (to preserve secure actual request header).

sid0• 16 years ago

If you're in an environment where you actually must use a proxy for some reason, you're in an environment that is probably going to ban arbitrary socket connections anyhow.

Not necessarily. For example, an SSL-encrypted connection would need the proxy to get out of the way. The defacto standard for this is HTTP CONNECT [1]. I understand there's a proposal to switch WebSockets to an HTTP CONNECT-based handshake.

[1] http://www.web-cache.com/Writings/Internet-Drafts/draft-luot...

tptacek3• 16 years ago

I can't think of a single BigCo client we have that doesn't put every one of its users behind a transparent proxy. Some of them cache, but all of them inspect, parse, and route HTTP.

You're right that most enterprises would never be OK with "allow arbitrary outbound socket connections", but most of the people building WebSockets applications don't want arbitrary outbound sockets; they just want an HTTP connection with finer-grained control over I/O.

mike-cardwell• 16 years ago

The long polling technique that people currently use is good enough for the vast majority of cases, so I don't mind if WebSockets takes another few years to develop into something final. There's no need to rush out a protocol here. I'd rather they released something good.

DjDarkman• 16 years ago

> Unfortunately, this will not happen in time for the release date of Firefox 4.

Then why release? Why release a product that is clearly not ready? Think about the developers for a second!

drdaeman2• 16 years ago

What I don't get is why they're not disabling Java and Flash support too, then?

WebSockets Disabled by default for Firefox 4

Related Stories