WebSocket Security - The Definitive Guide to HTML5 WebSocket - page 136

convinced the working group that WebSocket was dangerous to standardize without
some protection against these possible attacks. How could poisoning be prevented? After
much contentious debate by the working group, masking was added to the WebSocket
Protocol. Masking is a technique for obscuring (but not encrypting) the protocol contents
to prevent confusion in transparent intercepting proxies. As discussed in Chapter 3,
masking transforms the payload of each message sent from browsers to WebSocket
servers by XORing the contents with a few random bytes.
Previously, we mentioned that plugins and extensions can open sockets if they
request permission, and that installed applications use network connections with
arbitrary traffic all the time. What's stopping someone behind such a proxy from opening
a terminal and crafting that kind of network traffic manually? The answer is: nothing
at all. Masking does not fix the problems in the proxies, though it does not exacerbate
an existing problem. On the Web, where applications are not installed and you run
thousands of scripts from different sources simply by browsing around, everything is
magnified. Web APIs have to be more paranoid.
Like origin, masking is a security feature that does not need to be cryptographically
secure against eavesdropping. Both ends and any middlemen can understand the
masked payload if they desire. However, for middlemen who do not understand the
masked payload, they are critically protected from misinterpreting the content of
WebSocket messages as HTTP requests and responses.

Secure WebSocket Uses TLS (You Should, Too!)
As we discussed in Chapter 3, the WebSocket Protocol defines WebSocket ( ws:// )
and WebSocket Secure ( wss:// ) prefixes; both connections use the HTTP upgrade
mechanism to upgrade to the WebSocket Protocol. Transport Layer Security (TLS) is the
protocol used when accessing secure websites with a URL that begins with https:// . TLS
protects data during transit and verifies its authenticity. WebSocket Secure connections
are secured by tunneling through TLS using the WebSocket Secure (WSS) URL scheme
wss:// . By securing WebSocket communication with TLS, you protect the confidentiality,
integrity, and availability of your network communications. In this chapter, we focus
on confidentiality and integrity as they pertain to WebSocket security, and explore the
benefits of TLS from a deployment standpoint in Chapter 8.

■ Note TLS has its own RFC defined by the iETF: http://tools.ietf.org/html/rfc5246 .

You can use a plain, unencrypted WebSocket connection (prefixed by ws:// ) for
testing or even simple topologies. If you are deploying a service on a network, the benefits
of wire-level encryption are enormous and the drawbacks are relatively small.
The major historical drawbacks of using encryption on the Web have all been greatly
reduced with enhancements to the TLS protocol and modern machines. In the past, you
might have chosen not to use HTTPS due to high CPU cost, lack of virtual hosting, and
slow startup times for new connections. These concerns are now allayed with modern
improvements.