Re: [hybi] WebSockets

Ian Hickson <ian@hixie.ch> Tue, 31 March 2009 03:15 UTC

Return-Path: <ian@hixie.ch>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F753A67D8 for <hybi@core3.amsl.com>; Mon, 30 Mar 2009 20:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level:
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcX02B0o5-i8 for <hybi@core3.amsl.com>; Mon, 30 Mar 2009 20:15:21 -0700 (PDT)
Received: from looneymail-a5.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 18EA23A65A6 for <hybi@ietf.org>; Mon, 30 Mar 2009 20:15:21 -0700 (PDT)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a5.g.dreamhost.com (Postfix) with ESMTP id E0035122544; Mon, 30 Mar 2009 20:16:19 -0700 (PDT)
Date: Tue, 31 Mar 2009 03:16:19 +0000
From: Ian Hickson <ian@hixie.ch>
To: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <7B624611-7368-4B5F-B043-C0D96C94E359@gbiv.com>
Message-ID: <Pine.LNX.4.62.0903310308470.25058@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0903302124580.25058@hixie.dreamhostps.com> <BBB4A96C-6101-43C5-AF62-2E242EE64B31@gbiv.com> <Pine.LNX.4.62.0903310201130.25058@hixie.dreamhostps.com> <7B624611-7368-4B5F-B043-C0D96C94E359@gbiv.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSockets
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 03:15:22 -0000

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/)


> > 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! :-)


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


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


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


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

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