HTML and CSS Reference
In-Depth Information
The server reads the value of the
Sec-WebSocket-Key
header and performs the
following steps:
1.
Server adds GUID:
258EAFA5-E914-47DA-95CA-C5AB0DC85B11
Server transforms result with SHA1 hash
2.
3.
Server transforms result with Base64 encoding
4.
Server sends result back as the value of the
Sec-WebSocket-Accept
header
By performing a specific transformation of the provided key, the server proves that it
specifically understands the WebSocket Protocol, as a server that doesn't know the hash
isn't really a WebSocket server. This transformation heads off direct cross-protocol attacks,
because real WebSocket clients and servers will insist on only talking among themselves.
HTTP Proxies and Masking
In Chapters 2 and 3, we discussed WebSocket frames, which comprise WebSocket
messages. WebSocket frames sent from browsers to servers are masked to obfuscate the
frames' contents, because intercepting proxy servers can be confused by WebSocket
traffic. In Chapter 3, we discussed how masking WebSocket frames improves
compatibility with existing HTTP proxies. There is, however, another, rather unusual and
subtle reason for masking that has to do with security.
Unlike regular HTTP request-response traffic, WebSocket connections can remain
open for a long time. In older architectures, proxy servers are configured to allow such
connections and can handle the traffic gracefully, but they can also interfere with
WebSocket traffic and cause headaches.
A proxy server acts as an intermediary between a client and another server, is often
used to monitor traffic, and can sometimes close a connection if it has been open too
long. Proxy servers may choose to close long-lived WebSocket connections because the
proxy server sees the connections as trying to connect with an unresponsive HTTP server.
Figure
7-2
shows a simple example of a network topology with WebSocket, proxy
servers, and web applications. Here, client applications in a browser access back-end
TCP-based services using a WebSocket connection. Some of these clients are located
inside a corporate intranet, protected by a corporate firewall and configured to access
the Web through explicit proxy servers (see Figure
7-2
); these proxy servers may cache
content and provide some level of security. Other client applications access a WebSocket
server directly. In both cases, the client requests may be routed through transparent
proxy servers.
