- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 9 Dec 2010 14:30:38 +1100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Brian McKelvey <theturtle32@gmail.com>, Joe Mason <jmason@rim.com>, Maciej Stachowiak <mjs@apple.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
One other thing -- On 09/12/2010, at 2:03 PM, Bjoern Hoehrmann wrote: > I think the working group has heard all the notable techniques, as you > say if ultimately the browser controls all the bytes, then there is no > risk; if the attacker cannot control bytes that are critical for any > reasonable exploit, such as white space characters, then there is no > plausible risk either; if we do not use ports commonly used for HTTP, > and make initial communication look much unlike HTTP, there is also no > plausible problem. If we never actually leave the HTTP realm, such as > by using chunked encoding with two essentially infinite streams, then > there is also no plausible risk; finally there are the "talisman" pro- > posals, where you send something odd and hope for the best (Ian's "76" > draft has a "send malformed HTTP message" approach, Adam et al. have > the "CONNECT" approach, Dave Cridland suggests sending something that > looks like a CONNECT request but really isn't, and there are some ping > pong hello and goodbye proposals I haven't kept track of; there is a > plausible risk to all of those, but it's far fetched and evidence does > not support that there is a grave concern. I still haven't seen anyone explain why CONNECT is better than, say, WEBSOCKET_PLEASE. Also, from a quick read of the archive, it appears that encoding the stream (e.g., XOR, removing newlines, etc.) was shot down very quickly because people couldn't do sendfile(). That makes me wonder: what are the use cases for using sendfile() with WebSockets that can't be addressed by HTTP (more reliably, by everything I've seen here)? -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 9 December 2010 03:31:11 UTC