W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [hybi] workability (or otherwise) of HTTP upgrade

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 08 Dec 2010 22:21:23 -0800
Cc: Mark Nottingham <mnot@mnot.net>, hybi HTTP <hybi@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <36DC5313-2555-46AC-B618-B4FFCBD99C7D@apple.com>
To: Jack Moffitt <jack@collecta.com>

On Dec 8, 2010, at 8:10 PM, Jack Moffitt wrote:

> One path is to combine the separate port idea along with the
> encryption based approach. On the WebSocket port, you could avoid all
> the intermediary issues, but perhaps be limited by firewalls.
> However, you would not need any obfuscation and could easily use
> sendfile().  On the TLS port you use NPN to get a WebSocket that is
> not going to cause security problems with intermediaries.
> 
> For the short term, we get WebSocket on the port with the highest
> success rate, and in the long term, we have firewalls accepting the
> new port as killer applications make people care.
> 
> If we're going to lose the sendfile(), why not go the rest of the way?
> Or is there something I'm missing in the port 80 but just XORed case?

If the attacker can choose an arbitrary port to connect to, then you still need some form of obfuscation or attempt to avoid looking like valid HTTP, since they could chose port 80, 8080, 8000, or other ports not infrequently used for HTTP.

Regards,
Maciej
Received on Thursday, 9 December 2010 06:22:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT