Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

[Zhong Yu <[e-mail]>]

With Upgrade handshake, only 1 (out of 50K) firewall circumvention
attack was successful. While with POST/Java/Flash, the number is
around 1000. The Upgrade handshake is a huge improvement! But why? I
assume that the random bytes and framing bytes in the -76 handshake
corrupted HTTP streams and busted 99.9% of HTTP parsers.

In the singular successful case, the transparent proxy ignored these
non-http bytes and constructed a http request anyway, at least, it
extracted the "Host" header. For this attack to be really useful, it's
not enough that the bytes are tunneled to target.com. The proxy must
strip non-http bytes and send a compliant http request to target.com.
Or, the proxy forwards all bytes to target.com, and target server
strips non-http bytes and reconstructs the intended http request. Did
one of these two things actually happened in the experiment?

Even worse for the attacker, it's highly unlikely that the http
response sent back by target.com will be accepted by the WebSocket
client as valid WebSocket stream. If the attacker cannot read the
response from target.com, this attack is less useful than sending a
simple HTTP request.

The combined odds that this attack works over Upgrade handshake is
extremely small.

With CONNECT handshake the same transparent proxy did not pass through
the firewall circumvention attack. It is very likely that the proxy
routes by Host for each request. The handshake contains an invalid
Host, the routing failed, the connection was aborted, and the attack
couldn't be carried out. Most likely CONNECT wins over Upgrade on this
single case because of the bogus Host header, not because the proxy
understands CONNECT and gives up parsing the rest of stream.

Altering the semantics of Host is a big deal. Even though it turns out
to be "helpful" in this singular case of the experiment, the price far
more exceeds the benefit.

It should be stressed that the paper contains no empirical evidence
that the bogus Host would be helpful in other threat models.

If Host really is a problem, we should simply remove it from
handshake. Having no Host header is not worse than having a bogus Host
header. The Host header was a hack anyway because the request URI
wasn't absolute. We don't have to keep that hack for WebSocket.

I'm voting for CONNECT method with real Host header.

= Inconsistent data regarding cache poisoning attack =

Although the Upgrade handshake reduced firewall circumvention attack
to 1/1000, it does not have the same luck with cache poisoning attack,
according to the paper. 50% attacks still got though. That is *very*
surprising. Caching proxies must demarcate requests precisely, how do
they have such a higher tolerance of corrupt stream? How come 99.9%
host-based-routing proxies are busted by the stream, yet 50% of
ip-based caching proxies are not busted? I must respectfully
disbelieve the result for now.

- Zhong Yu