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

[John Tamplin <[e-mail]>]

On Wed, Dec 8, 2010 at 10:55 PM, Mark Nottingham <[e-mail]> wrote:
> CONNECT to a server (intermediary or origin) that isn't expecting it can
> and will be treated like any other method that isn't understood -- it's
> perfectly legitimate for a server to generate a 405 Method Not Allowed.

Sure, and in such a case no WebSocket frames will be sent on the
connection and no attack can take place.

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.

That doesn't mean that such intermediaries do not exist, but it does seem
to indicate that CONNECT is stronger than GET+Upgrade regarding
confusing transparent intermediaries.

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

If the destination server is not a WebSocket server, then it will not pass
the handshake test and therefore no WebSocket frames will transit the
intermediary.

>> I think there is a rough consensus to do some XOR obfuscation if that
>> is necessary or helpful, even though some would rather be able to do
>> the easy sendfile() call instead, but the benefits are not very clear
>> (if the attacker learns or can predict the XOR key, you've not gained
>> much, in some scenarios anyway.)
>
> 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.

-- 
John A. Tamplin
Software Engineer (GWT), Google