Re: [hybi] WebSockets

[Ian Hickson <[e-mail]>]

On Tue, 31 Mar 2009, Roy T. Fielding wrote:
> > > >
> > > > Note that the way WebSocket is designed, there's no deliberate 
> > > > fooling; it's a straight up HTTP Upgrade attempt.
> > > 
> > > Not quite.  You can't place constraints on specific ordering of 
> > > bytes within WebSocket and then claim it is HTTP
> > 
> > You're right; my bad. It's not a straight-up HTTP Upgrade attempt. 
> > It's a WebSocket handshake that happens to act like an HTTP Upgrade 
> > attempt in practice. There is indeed deliberate fooling at the 
> > server-side; my point was that there is no deliberate fooling at the 
> > level of security policies.
> > 
> > (The handshake is designed that way so that non-HTTP victim servers 
> > can't be tricked into sending back what looks like a valid response: 
> > we have to have as strict a handshake as possible so that there is as 
> > little room for attacks to maneuver in as possible.)
>
> I think the same goal is accomplished by any valid HTTP/1.1 message.

It seems that the implementation work of checking whether a response is a 
valid HTTP/1.1 message is significantly more complicated than the work of 
determining whether the Web Socket handshake is precisely correct or not.

It also seems far easier to reason about the security aspects of the 
handshake as seen by the servers of other protocols when the handshake is 
a very well-defined series of bytes than when the handshake is an 
open-ended set of possible requests. Similarly, it's a lot less likely 
that an attacker could trick an arbitrary protocol's server into 
outputting the exact sequence of bytes that the Web Socket handshake 
requires than it would be if the handshake consisted of any sequence of 
bytes that matched the HTTP grammar.


> > > However, it could still be used to trigger arbitrary requests by 
> > > intercept proxies that don't understand that the connection has been 
> > > upgraded.
> > 
> > Could you elaborate on this? An example would be very useful.
> 
> I mean that, after the initial constrained Upgrade request is accepted 
> by the server, there is nothing to prevent the WebSocket sender from 
> continuing with a sequence of HTTP requests on the same connection that 
> might be inspected and redirected by an interception proxy (thinking 
> that they are just pipelined normal HTTP requests).

Surely that would be a bug in the proxy.


> > > Alternatively, just use a different port and let the organizations 
> > > decide whether they want to allow such connections through their own 
> > > firewalls.
> > 
> > As designed, WebSocket doesn't default to the HTTP ports. The proposal 
> > has its own port. To use the HTTP ports you have to explicitly 
> > override the default, just like HTTP can be tunnelled over ports other 
> > than port 80.
> 
> In that case, you really are looking for a different protocol rather 
> than just reusing an HTTP connection.

Yes, the Web Socket protocol is its own protocol. Is that not clear in the 
Web Socket Protocol Internet Draft?

The ability to bootstrap using an HTTP connection, Upgrade:ing to 
WebSockets, is optional, and is only intended for advanced users that need 
to reuse the same port for both purposes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'