Re: [hybi] Moving to a CONNECT-based handshake

[Willy Tarreau <[e-mail]>]

On Wed, Dec 01, 2010 at 12:21:46PM -0800, Roy T. Fielding wrote:
>   b) obfuscate the data sent via websockets in some way that the client
>      page cannot control or deceive. [e.g., encryption, gzip with a fixed
>      dictionary, or escaping LF in data.]
> 
>   c) establish post-handshake framing that prevents subsequent data
>      from being interpreted as an HTTP request or response.
>      [e.g., inserting a 'W' after every LF in data.]

That's why Greg and I keep saying that the framing definitely has an impact
on the whole thing and the handshake does not have to cover everything by
itself (which was proven by Adam's experiments BTW : handshake without WS
data can fool some proxies).

In my opinion, if we can have a framing that never sends an LF (or even
neither a CR nor an LF), there is no way a WebSocket request or response
can be misinterpreted as HTTP. And doing that is not necessarily difficult.
We could think about escaping them or also to work on 7-bit with one bit
always set (eg: bit7==1).

I still find it better to make the protocol safe by design than to try to
escape some known gray areas with some paint, and I'm still convinced that
the framing has a much more important role to play here than the handshake
considering that we want to ensure a buggy intermediary will not accidentely
take the data for an HTTP request.

> Note that none of the above has anything to do with Upgrade or the method used
> in the initial exchange.  Labeling the paper as discovering a vulnerability in
> the Upgrade handshake is misleading and unethical.
> 
> Adam's solution (and EKR's usual hammer) is to use TLS encryption.  That is
> fine when it satisfies the protocol use cases, but not so great when it
> doesn't.

To be honnest, at one point I wondered whether the goal of the paper wasn't
to get everyone reject it so that we can conclude that HTTP was not usable
and that TLS was the only remaining solution :-/

The sad part is that if we had finished the work on the HTTP handshake
earlier without agitating that many strawmen, we could already be working
on a TLS variant !

> A more sensible test would have been to use a new method, like WEBSOCKET,
> since then at least the initial handshake could remain HTTP-compliant.

It has already been explored, but it happens that stupid proxies have no
reason to make a difference between that an a GET, so if they can fail on
a GET, they can fail on a new method. The point beind the CONNECT is that
it's already a known method with known semantics, eventhough it also has
its share of issues. Alternatively, "OPTIONS *" is also well-defined and
may have less risks of being mis-routed by quick-n-dirty proxies.

> BTW2, "transparent proxy" != "intercept proxy".  A proxy is called transparent
> when it doesn't transform the messages exchanged, unlike intercepts (which
> aren't even true proxies since they are unknown to the client).  Please use
> the correct terminology.

I see varying terminologies for that, and I think that it's been caused by
the combined used of such proxies with traffic interception. It's common
to call such proxies "transparent" when they're not declared by the user,
as they're transparent to the user. Thus they act as intercepting proxies.
I often call them reverse-proxies, which is well understood on the server
side but much less on the client side! However I tend to prefer the wording
"gateway" from the HTTP spec is better because it does not preclude one
specific usage. But when explained to network people it creates confusion...

Regards,
Willy