5 ms·
Maybe someone could explain the original security concern, and how masking is able to address that concern?
by palish 15y ago
Maybe someone could explain the original security concern, and how masking is able to address that concern?
- tptacek 15y agoIn 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.
- yuhong 15y agoTo be more precise, obfuscation.
- tptacek 15y agoThat would indeed be more precise, but it would also be bad writing. And my writing needs all the help it can get.
- necubi 15y agoWhat does this mean for servers? Do we need to support both versions of the protocol for now? Is that even possible?
- tomjen3 15y agoThat seems like a horrible solution - now we have to wait until all companies update their proxies to support websockets.
- mbrubeck 15y agoNo, 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.
- abarth 15y agoThe full details are here: http://w2spconf.com/2011/papers/websocket.pdf http://w2spconf.com/2011/papers/websocket.pdf (Full disclosure: I'm a co-author of that paper.)