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

On 09/12/2010, at 4:45 PM, John Tamplin wrote:
> 
> Adam's experiment found cases where transparent intermediaries did not
> treat GET+Upgrade as any different from GET (and therefore the following
> frames were interpreted as HTTP), while they found none that treated
> frames exchanged after a successful CONNECT as if they were HTTP.

Adam's experiment was a bit more than 50,000 requests. That's hardly conclusive.


>> As such, using CONNECT isn't a guarantee that the message framing
>> has changed on the request, until the server agrees to its semantics.
>> Given that those semantics are specific to configured proxies, and an
>> intermediary "agrees" by forwarding the message even when it doesn't
>> understand its semantics, this is indeed an entirely hope-based
>> assumption; that every intermediary (firewalls, virus scanners, caching
>> proxies) is built to understand CONNECT, even when many of them
>> can't be configured as an explicit proxy at all.
> 
> Transparent intermediaries are by definition not configured into the browser.
> They don't know what the browser is actually connecting to when they
> view and possibly intercept the presumed HTTP traffic.  As such, they
> already have to be written to assume the browser might in fact be
> connecting to a non-transparent proxy, so the presence of a CONNECT
> method should not be unexpected.

You're basically asserting that the security of WebSockets relies on all vendors of intercepting proxies implementing to meet this use case. 


>> I was thinking more about stripping newlines, etc., but yes, it's more
>> expensive. Just not sure why that's an issue, which is why I asked...
> 
> Some people worry about servers that have to terminate a very large
> number of WebSocket connections, so the memory and CPU
> requirements do matter.
> 
> I think stripping newlines or padding is more expensive to overall
> performance than doing XOR or encryption, since the number of
> bytes change and now you have to make a second pass through
> the frame to get the correct length, or require the reader to do it a
> byte at a time.
> 
> At least XOR with a per-frame key adds a fixed number of bytes,
> so you can just add that to the frame length received from the
> upper layer.


That makes sense. 

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 9 December 2010 06:10:18 UTC