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

["Roy T. Fielding" <[e-mail]>]

On Dec 1, 2010, at 8:45 AM, Ian Fette (イアンフェッティ) wrote:

> We all know that WS over port 80 faces obstacles. That's been known for a long time, nothing has changed, and yet there remains a group that wishes to try to use it. As long as the problems are known, I see no reason to try to forbid it. 
> 
> As for strong objectors, it seems like many people who are implementing have voiced strong support for adams proposal, modulo some tweaks here and there. I would like to see how far we can get.

We will get nowhere.  Adam's proposal is to use CONNECT, a method specifically
designed for telling a normal (non-intercept, non-reverse) proxy to create a
TCP tunnel to some other host:port, and he suggest using it to do something
contrary to its method definition and the HTTP architecture in general.
That would violate both CONNECT semantics and the HTTP syntax for non-proxy
requests (not to mention our hybi charter).  Please understand that such an
abomination will not be allowed in an Internet proposed standard even if the
browsers deployed it, and thus should be rejected out of hand.

Listen to the input you have received already.  The vulnerability described
in Adam's paper has nothing to do with the Upgrade handshake -- they
specifically did not test the actual handshake.  What they did is test the
post-handshake non-encrypted connection for intercept proxies that might
(in 8 out of 47,338 cases) mistakenly interpret the unencrypted channel
after the handshake is completed (or ignored).  Thus, it represents
an attack on any non-opaqued channel that is being scanned by caching
intercept proxies (an architecture that is not condoned by HTTP but does
occur in some limited practice by idiots) when a browser is allowed to
send arbitrary bytes over that channel.

One question, therefore, is whether it is important to protect the 0.0169%
of users behind networks that are deliberately using an insecure and invalid
form of HTTP proxy from yet another attack based on that invalid usage.
YMMV.

If it is important, then the solutions are

  a) never use low-numbered ports for websockets [my preference]

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

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.

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.

BTW, Upgrade was not designed for establishing TLS connections.  Some people
tried to use it that way, three years after it was designed for HTTP/2+,
and failed to get any adoption because Upgrade is hop-by-hop and that's not
what users want from a TLS encrypted stream.  Likewise, using CONNECT to
establish secure tunnels through proxies fell out of favor a long time ago.
The practice of moving such tunnel-oriented behavior onto a separate port has
the benefit of relieving the non-encrypted infrastructure from having
to deal with the very different behavioral and resource-intensive
characteristics of secure connections, which is why I prefer (a) above
whether or not we use TLS (websockets are not the web and do not belong
on port 80).

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.

....Roy