Web Security Journal: There's been a flurry of discussion this week among Internet and Web standards heavy-hitters around WebSocket, the new communications protocol supported in Chrome 4 and Safari 5. What was the main issue? Is there some kind of fundamental security vulnerability with the WebSocket (WS) protocol?
John Fallows: When surfing the Web, our browsers may communicate with Web servers via HTTP proxies that deliver many benefits, such as providing previously cached Web content more efficiently than repeatedly contacting the target server. These proxies may be either explicitly configured at the browser or they may form part of the general network topology to intercept the communication path implicitly. Securely encrypted Web communication cannot be intercepted by such proxies.
Members of the Hypertext Bidirectional (HyBi) IETF Working Group recently completed a study to test the vulnerabilities of these implicit, intercepting HTTP proxies. The study found that the raw socket capabilities of Flash and Java could be used to mount an attack on these intercepting HTTP proxies, such that an attacker might be able to influence the contents of the cache and change the behavior of specific sites for users accessing those sites through the same intercepting HTTP proxy.
The results showed that of the 47,338 intercepting HTTP proxies tested with the unencrypted WebSocket handshake alone, 0.37% and 0.017% were found vulnerable for the two specific attacks described in the study.
Web Security Journal: If the flaw lies not in WebSockets, but in some particular type of proxies, why are commentators inclining towards discussing WebSockets and only WebSockets?
Fallows: If all intercepting HTTP proxies correctly implemented the HTTP standard, then the 101 Switching Protocols response used by WebSocket handshake would be both sufficient and elegant.
Even though these intercepting HTTP proxies vulnerabilities have been enabled by Flash and Java for a long time, they were reported in the study as part of the IETF working group design process for the WebSocket wire protocol, therefore commentators have been inclined to comment specifically about the WebSockets portion of this result.
In the short term, browser providers have elected to temporarily withdraw the JavaScript WebSocket API from deployed browser implementations until they and others in the IETF working group reach agreement on how to bulletproof the WebSocket wire protocol to handle even buggy implementations of intercepting HTTP proxies. There are already proposals in place so I anticipate a timely resolution early next year.
Web Security Journal: The tests that spurred Mozilla and Opera to disable WebSockets as the default were done with Java and Flash clients. That means presumably that this issue has been around long before WebSockets? Why hasn't it been caught and dealt with before?
Fallows: The WebSocket wire protocol design effort has brought together a huge community of experts to deliver this functionality such that it can be deployed on a global scale, which necessitates such experiments to validate the standards compliance of deployed HTTP proxy infrastructure.
It will be interesting to see how Adobe and Oracle respond to address the vulnerabilities enabled by raw socket access in Flash and Java. Perhaps this will encourage them to adopt WebSockets as a native part of their platform, and have a more restrictive policy on raw socket access for Web deployments of their plug-in technologies.
Web Security Journal: What's the exact current status, then? The protocol is being standardized by the IETF as we speak, but what about the WebSocket API overall? What's its status vis-a-vis the W3C?
Fallows: The W3C JavaScript WebSocket API remains unchanged in its definition. However, browser providers await resolution of the WebSocket wire protocol at the IETF before deploying an implementation.
Web Security Journal: So is it accurate to describe WebSockets - still - as an early stage specification at the moment?
Fallows: The WebSocket wire protocol is currently in the IETF Internet Draft stage, and there is no shortage of support or dedication in the Hypertext Bidirectional Working Group to reach completion in a timely manner.
Web Security Journal: You mentioned earlier that there's no real barrier to improving the WebSocket protocol the moment it is bulletproofed to withstand broken infrastructure, since such an improvement can simply be included in the latest update of whatever browser a user is using. But the creator of JavaScript, Brendan Eich, has warned that we might end up with what he calls "version skew" because users won't necessarily switch browsers just to get the latest version of WS. He asks, rhetorically: "Are we going to synchronize Firefox's release cycle with Chrome's? Is Opera? Is Safari?" Isn't that a valid concern?
Fallows: Web browsers have always innovated beyond the standards, in part to differentiate themselves and in part to drive the standards forward with the benefit of real-world experience. WebSocket is a good example of that, having evolved beyond both Ajax and Comet, as well as raw socket communication provided by plug-ins. If we are careful to provide a stable and extensible WebSocket base, as was achieved with HTTP, then I would fully expect to see browsers implementing custom enhancements to that base, and it will be the responsibility of WebSocket gateway providers to support for those enhancements.
Web Security Journal: Mozilla, despite disabling it as the default in Firefox 4, says it is "excited" by WebSockets. Why is such a major browser player "excited" - what is it about WebSockets that gets a major Internet force like the Mozilla Foundation to be so upbeat about its potential?
Fallows: WebSockets, and HTML5 in general, represent a leap forward for the Web application platform and it is certainly an "exciting" time for all of us using the Web today. For decades we have seen the evolution of Web applications with gradually increasing interactivity getting closer and closer to their desktop installed counterparts. WebSockets allows us to add the final piece of that puzzle, providing desktop class TCP network connectivity while traversing the HTTP-constrained infrastructure of the Web. A new breed of applications can now be built using WebSocket with a fraction of the server-side infrastructure costs, optimized network bandwidth utilization and more immediate delivery of time-sensitive information.
Web Security Journal: And where does the WebSocket protocol sit in terms of HTML5 specification?
The WebSocket wire protocol is governed by the IETF who manage many of the world's protocols like HTTP, FTP, SMTP, and others.
The W3C standards body maintains the both HTML5 specification and the WebSocket API specification which defines how JavaScript applications can leverage WebSocket functionality.
Browser providers depend on both standards to fully deliver WebSocket functionality.
Web Security Journal: Adam Barth, whose paper on a possible exploit of transparent proxies sparked this latest discussion, has also described a handshake for the WebSocket protocol that resists cross-protocol attacks. Is that the direction the IETF will go do you think?
Fallows: Ultimately there are a few ways to proceed that balance HTTP compatibility with strategies to overcome non-compliant HTTP proxies. Given that the same study demonstrated no successful attacks on Adam's proposed enhancement to the WebSocket handshake, it seems to be a very strong candidate as we move forward.
Web Security Journal: Can't a WebSocket connection simply be encrypted? Wouldn't that render this whole issue moot - or is that too simplistic?
Fallows: The attacks identified by Adam Barth's paper would not be possible using an encrypted WebSocket connection because the HTTP proxy would not be able to see the encrypted wire traffic and could therefore not be confused into triggering the buggy behavior. If the browser providers restricted encrypted-only access to WebSockets then this issue could be avoided.
Web Security Journal: So from a Kaazing perspective, then, is it your intention to propagate the world with WebSockets and then go to sleep with the feeling of a job well done, or is the propagation of WS gateways the means to some other kind of business goal?
Fallows: At Kaazing, we believe that WebSockets is the beginning of a new future for Web applications as we move from the disconnected world of yesterday to the always connected, always up-to-date world we live in today. We understand that while WebSockets provide the foundation of that new beginning, the majority of the new capabilities lie in how you use WebSocket to support higher-level protocols that make it straightforward to solve technical challenges that would have taken significantly more effort to achieve otherwise.
Our goals are to help to world transition to this new standard easily and efficiently, and continue to deliver solutions that eliminate the unnecessary architectural complexity found in many Web applications today.
Web Security Journal: And is anybody yet finding that they can make more money, or spend less, because of Kaazing's offerings? Are there real-world implementations at all?
Fallows: We have customers in the Financial Services, Sports Betting, and Online Auctions markets that have used our technology to reduce infrastructure costs, reduce time-to-market, improve end-user experience and drive their revenues more efficiently.
Web Security Journal: What, in your view, is the best way of channeling developers' interest in experimenting with what a WebSocket gateway can do for their architecture? How can someone who is not yet au fait with the technbology most easily play catch-up?
Fallows: The WebSocket.org site is dedicated to explaining the various aspects of WebSocket technology and would be a useful starting point for those wishing to read up. It contains links to the relevant WebSocket API and wire protocol specifications, including a discussion of the many benefits of WebSockets.
A developer download of Kaazing WebSocket Gateway is also freely available from kaazing.com. This delivers emulation of the standard WebSocket API for all browsers. So in the interim until browser providers re-enable WebSockets, developers can still experiment with the same WebSocket APIs in both current and older browsers that will prepare them for the future of Web communication.
Subscribe to Web 2.0 Journal Email News Alerts
Subscribe via RSS
