Re: [hybi] WebSockets

["Roy T. Fielding" <[e-mail]>]

On Mar 30, 2009, at 8:16 PM, Ian Hickson wrote:
> On Mon, 30 Mar 2009, Roy T. Fielding wrote:
>>
>> Thanks.  Perhaps we should start a wiki somewhere to list the use  
>> cases
>> and then a protocol comparison table to see what use cases are  
>> satisfied
>> by each protocol.
>
> As far as I know, all the use cases are addressed by all the proposed
> protocols. However, please be my guest if you would like to start  
> such a
> page; I'm happy for people to use the WHATWG wiki for that purpose  
> if the
> question is which wiki to use. (http://wiki.whatwg.org/)

I created an initial page at

   http://trac.tools.ietf.org/bof/trac/wiki/HyBi

which I think is an appropriate place for it.

>>> For my use case (the trains) I'm fine with not doing any tunneling,
>>> however it turns out that a lot of sites block all but port 80 and
>>> port 443 and yet people still want to use their IM clients. Right  
>>> now
>>> Web applications like GMail are tunneling through ports 80 and  
>>> 443 by
>>> abusing HTTP; I think it would be much better to have them  
>>> Upgrade to
>>> another protocol and leave HTTP for REST-like purposes.
>>
>> A lot of offices put locks on the door and only give keys to their
>> employees and trusted contractors.  That is inconvenient for a  
>> reason.
>
> I'm not making judgements about whether ignoring these IT policies  
> is a
> good idea, or whether the IT policies themselves are good ideas;  
> I'm just
> conveying what requirements people have put forward. There would be no
> point us designing a protocol that doesn't handle cases that we  
> have been
> told are critical, after all! :-)

On the contrary, ethics are a part of engineering that the IETF follows
better than most SDOs.

>>> 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.

>> 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).  For more info, see

http://www.thesecuritypractice.com/the_security_practice/ 
TransparentProxyAbuse.pdf

I don't know if they are worth designing around, but I do know that
they are avoided by using the different TCP ports, encrypting the
stream, or using a more constrained protocol after the upgrade
such that the client API generates the message framing in a way
that can't be misconstrued.

Routing of requests in HTTP over TCP depends on both the IP address/
TCP port and the value in the Host header field.  In particular, the
same-origin requirement of web page script/plugin processing is only
effective with HTTP if both the TCP/IP parts and the Host correspond
to the same-origin host:port.  If the TCP/IP doesn't match, then the
message will be directed to some other server.  If the Host (or the
absolute URI for proxy requests) does not match then any host on
a shared IP address (think large ISPs like dreamhost or clouds
like AWS) can bypass the same-origin policy for any other hostname
on the same ISP/cloud.

WebSockets is much better in that regard than some implementations
that provide raw socket-like access to web page components without
sending an initial HTTP request.

>> A more secure design would require the use of CONNECT and then  
>> forcibly
>> encode the stream such that it can't be misinterpreted.
>
> This is what is done for the SSL variant of WebSocket.

Yep.

>> 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.  I guess I should get back to
working on the waka spec.

....Roy