wikipedia appears to infers websockets are secure:
For web browser support, a secure version of the WebSocket protocol is implemented in Firefox 6 (named MozWebSocket),[2] Google Chrome 14[3] and Internet Explorer 10 developer preview.
… Although there are no known exploits, it was disabled in Firefox 4 and 5…
but w3 states they are insecure:
Following HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the Internet, even if the script checks that the URL has the right hostname.
-
are
http websockets(ws:) secure or not? -
are
https websockets(wss:) secure or not? -
if not #2, are there documented prophylactic measures?
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.