Hacker News Reader

Comment by palish | Hacker News Reader

Maybe someone could explain the original security concern, and how masking is able to address that concern?

In the original protocol, it was possible to get two endpoints to transact over Websockets even if a middlebox between them didn't perfectly enforce the protocol. This is bad because it potentially confuses the middlebox about which parts of the stream are HTTP/1.1 requests or not, which can allow attackers to poison caches.

In the new protocol, Websockets traffic is (trivially) encoded so that it (a) can't accidentally be interpreted by either endpoint as something other than Websockets and (b) can't confuse middleboxes.

Basically, "new" Websockets has custom Websockets encryption that nothing other than Websockets will be speaking, so, if you're talking Websockets, it's because both endpoints consented to do so.

To be more precise, obfuscation.

That would indeed be more precise, but it would also be bad writing. And my writing needs all the help it can get.

What does this mean for servers? Do we need to support both versions of the protocol for now? Is that even possible?

That seems like a horrible solution - now we have to wait until all companies update their proxies to support websockets.

No, just the opposite - this change was necessary to get WebSockets to work with old, broken proxies. Previously those proxies might interpret part of the body of the WebSocket traffic as an HTTP header; now they will correctly just pass the traffic through.

The full details are here:

http://w2spconf.com/2011/papers/websocket.pdf

(Full disclosure: I'm a co-author of that paper.)

Reply on news.ycombinator.com