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.
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.
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.
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.)
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Why take such an aggressive and accusatory tone? You don't have to reply with such vitriol.
Secondly, I didn't actually say websockets were insecure; I said if they were, then Firefox is sensible not to include them.
Third, even if the websocket protocol is secure in theory, if the majority of proxies don't correctly implement the upgrade header, then using websockets is insecure in practise.
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.
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.
Thats not entirely true, Websockets do initiate over http (by using the 'Upgrade' header so they can share port 80 with normal http traffic) but after the initialization handshake is finished the traffic no longer uses the http protocol.
It's a feature that the websocket upgrades from an HTTP connection. If your web server can support it, you can use your regular HTTP handler code to authenticate incoming requests and then upgrade to the websocket protocol.
The API is not the only difference between HTTP and websockets. HTTP follows the request response pattern. A websocket is a pair of message streams.
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.
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.
By changing some global variable in the callback and checking if it has changed in 'somethinghappened' (which only gets called after 5 seconds, giving the callback time enough to get called).
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.
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.
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.
Couldn't disagree more. You'd be shocked at the number of CE/CS majors that ignore Firefox updates and complain about them. My mom uses Chrome on my parents' laptop and my dad uses Firefox. Guess which one is out of date :).
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.