are websockets secure or not?

Question

wikipedia appears to infers websockets are secure:

For web browser support, a secure version of the WebSocket protocol is implemented in Firef

Answer 1

Version hixie-76 of the WebSocket protocol is more secure than earlier versions, and version hybi-07 is even more secure. At hixie-76 version is added protection against fake requests. At hybi-07 version is added message masking.

Answer 2

There are a lot of different aspects to WebSocket security.

The snippit from wikipedia that you quoted is referring to the masking of WebSocket client to server data. This is to protect misbehaving intermediaries (e.g. proxies and caches) from accidentally interpreting WebSocket traffic as normal HTTP traffic. The danger here is that the WebSockets protocol could be used to poison the caching intermediary. However, I should note that this was a purely theoretical concern, but it was enough of a concern that Mozilla and Opera were reluctant to ship the Hixie and early HyBi versions of the WebSocket protocol. So the IETF decided to add client to server masking of the data to address the concern.

As an aside, the IETF is responsible for the WebSocket protocol (IETF 6455) while the W3C is responsible for the HTML5 WebSocket API (the Javascript object, methods and events).

Another aspect to WebSocket security is cross-origin security. The second snippit you quoted from the W3C WebSocket API spec is related to cross-origin security. WebSockets support cross-origin connections (to a different host that the HTML page was served from). This warning is saying that if normal HTTP cross-origin procedures had been used for WebSockets, this would open up a huge security hole. However, the WebSocket procedure is different for exactly this reason. For one thing, the WebSocket handshake and response is designed so that WebSocket connections cannot be made to an HTTP server that does not support WebSocket connections: the server must sign/hash a key in a WebSocket specific way and return this in the handshake response. The second part is that the browser must send an Origin header as part of the handshake (this indicates where the HTML/Javascript was loaded from originally). This allows the server to choose which domains it will allow to originate WebSocket connections.

Finally, there are two WebSocket connection modes: unencrypted (ws://) and encrypted (wss://). The encrypted mode uses TLS/SSL encryption to encrypted all data sent to and from the server (including the initial handshake and response). This is the same encryption mechanism used for HTTPS connections (and uses the same encryption engine in the browser). This prevents third parties from snooping on the data being transferred.

There are really just two versions of the WebSocket protocol worth knowing about:

• Hixie76: This version of the protocol added cross-origin security and header hashing/signing. However, due to the way the protocol is designed it is difficult to add support for it to existing web servers. This is the version currently support in iOS (hopefully iOS 6 will finally update to IETF 6455)

• IETF 6455: This is the version of the WebSocket protocol that was standardized by the IETF last November (Nov 2011). It was the culmination of work by the IETF HyBi working group (iterations of the protocol leading up to it were labelled HyBi XX). This is the version supported by current versions of Chrome and Firefox and also by IE 10 and soon Opera.