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

On Dec 6, 2010, at 11:31 PM, Greg Wilkins wrote:

> I don't see the justification for the confidence in Adam's and Eric's
> proposal.   Basically they are saying that in their experiment sending
> the method "CONNECT" was sufficient to prevent intermediaries parsing
> any following HTTP requests.
> Yet when the suggestion of sending Get+Upgrade+Hello packets is made,
> to similarly trip up the parsers of intermediaries, the response is
> that HTTP parsers are forgiving and that empirical experiments of no
> exploit are not proof that it is safe etc. etc.     These arguments
> can be equally made against a CONNECT solution, as it is easy to
> believe that their are intermediaries that will treat CONNECT no
> differently from other methods and continue parsing the stream for
> HTTP content.

Empirically, it seems the number of servers confused in this way by CONNECT is significantly lower than the number confused by GET+Upgrade, to a statistically significant degree, and there are good odds that it is close to 0. There is a plausible theory to explain these facts - CONNECT is very often supported by proxies and other intermediaries with a specific behavior which precludes this failure mode. Meanwhile, GET+Upgrade is not used much, so intermediaries do something random and possibly bad when faced with it.

That being said, the Adam+Eric proposal also includes obscuring routing information and masking of the payload, which also defend against the intermediary attack.

Finally, we also need to worry about attacks on HTTP origin servers, WebSocket servers (against http attackers) and server side infrastructure, including in virtual hosting scenarios.

The Adam+Eric proposal is the best I have seen for addressing these threats.

> We need to do the experiment, but I expect we would find that a
> GET+Upgrade+Hello handshake would also have 0 exploits just like
> CONNECT.   But I do not believe that either zero result proves that
> either handshake is 100% safe, because essentially the issue is caused
> by poor intermediaries and we can always imagine more buggy
> intermediaries.

It's worth testing. But GET+Upgrade+Hello requires an extra round trip to set up the connection. Between an extra round trip and possibly violating the vaguely defined "semantics" of the CONNECT method, I'll take the semantics violation. 

Furthermore, GET+Upgrade+Hello doesn't do as good a job of defending against the other threat models we've discussed. You could combine it with masking of the payload and routing information, but at that point I don't think you could claim even a "semantics" advantage relative to CONNECT.

> After either "CONNECT" or "GET+Upgrade+Hello" we will need to have
> robust framing that gives a high probability of tripping up HTTP
> parsers on every message.    But for both handshakes, the defence is
> essentially probabilistic, because we cannot prove that there is not a
> really stupid intermediary out there.     I think it is just wrong to
> think that "CONNECT" makes us any  safe from this consideration.
> The question is, given that these intermediaries are already
> exploitable via commonly deployed browser plugins (and the victim does
> not even have to be running those plugins as another browser can do
> the poisoning), is a probabilistic demonstration of robust framing
> acceptable defence for either handshake?
> If the answer is no for one, then it is no for the other, because
> there is no difference in the proofs for either.   If the answer is
> no, then we need to consider encryption or another port.
> I do come back to the fact that using another port does not give a
> perfect success rate, but then neither does CONNECT or
> GET+Upgrade+Hello.    Opening new ports seams like an easier ask than
> convincing intermediaries to change their CONNECT and/or Upgrade
> handling.

It might be worth testing a new port (not 80 or 443 or any other well-known port) for success rate. It would also be worthwhile comparing TLS over port 443. It may be that 443 is the only option that gives a resonable success rate.


Received on Tuesday, 7 December 2010 08:08:19 UTC