Why are WebSockets without Sec-WebSocket-Key1 insecure?

Question

The old and superseded draft 75 of WebSocket specification doesn't specify HTTP request headers Sec-WebSocket-Key1 and Sec-WebSocket-Key2. Why does the latest draft include these, and what in terms of increased security?

Answer 1

Here is what I could figure out: these new fields are there to prevent cross-protocol attacks. Let's assume that some malicious JavaScript is running in a web browser, attempting to connect to non-HTTP, non-WebSocket servers (e.g. FTP, telnet, SSH). With draft 75, the handshake consisted of just the client sending the WebSocket handshake header, and the server replying with nothing. After that, the client could send \x00...\xFF framed messages. Thus the malicious JavaScript code in the client would have been able to connect to a non-WebSocket server (e.g. telnet), attempt to log in and run commands there. After Sec-WebSocket-Key1 has been introduced, the WebSocket connection attempt will fail unless the server returns the MD5 checksum of Sec-WebSocket-Key1 etc. Forcing a non-WebSocket (e.g. telnet) server to do that is almost impossible, especially because the JavaScript code has no control over Sec-WebSocket-Key1 etc.