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

Re: #250 / #251 (connect bodies)

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 28 Oct 2010 23:37:59 -0700
Message-ID: <AANLkTikPYGc1CzHGEhSuvWY71MnVXv7PF+4mXXMgQ+rh@mail.gmail.com>
To: Adrian Chadd <adrian@creative.net.au>
Cc: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Oct 28, 2010 at 11:28 PM, Adrian Chadd <adrian@creative.net.au> wrote:
> On Fri, Oct 29, 2010, Willy Tarreau wrote:
>> On Fri, Oct 29, 2010 at 04:41:14PM +1100, Mark Nottingham wrote:
>> > It's not free, as evidenced by the hoops that are being jumped through to try to make sure that it isn't treated like HTTP.
>>
>> No, we're trying to make sure it *is* treated like HTTP even on non
>> completely HTTP compliant stacks which could possibly treat the tunnelled
>> data as HTTP too while they must not. Otherwise, the 101+upgrade perfectly
>> fits the purpose.
>
> I know I've asked this before, but what about devices that wish to pull apart
> the CONNECT traffic (MITM security appliances) and, deciding the traffic
> isn't actually HTTP, quite rightly denies it?
>
> What about statistical fingerprinting of traffic? (ie, fingerprinting
> whether a CONNECT session is likely to be HTTP or not based on exchanged
> traffic patterns.)

All that stuff appears as a failure to establish a WebSocket
connection.  All the WebSocket handshakes we know have an empirical
failure rate of about 50%.  If you want to connect more reliably, you
need to use the TLS version.

Adam
Received on Friday, 29 October 2010 06:39:19 GMT

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