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

On 7 December 2010 08:04, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Dec 6, 2010, at 10:44 PM, Mark Nottingham wrote:
>> The difference is that we wouldn't have to figure out how to make it safe *and* compatible with the existing HTTP infrastructure; we wouldn't have to catch all of the accidental / deployment issues as well as the active attacks.
>>
>> That would make the way forward fairly simple:
>>
>> 1) Designate a new port for Websockets traffic
>> 2) Allow that to be overridden (much as with HTTP and pretty much every other protocol) for people who have immediate deployment considerations (i.e., they'll use 443)
>> 3) Design the protocol so that it can't spoof other protocols, by using a selection of techniques:
>>  a) Exchanging a nonce, with HMAC response
>>  b) Armouring each message
>>  c) Encrypting the whole damn thing
>> *without* the pretence that it's HTTP.
>>
>> I'm sure (3) is an oversimplification and/or just plain wrong, but that's why we have Adam. #1 gives us a long-term safe
> deployment strategy, whereas #2 lets the impatient deploy right away, and also gives a fallback if #1 doesn't take off in the long run.
>
> Adam and Eric's proposal basically does what you say, except that it doesn't designate a new port for
> WebSocket traffic, and it makes a small nod towards letting servers and server-side infrastructure
> dispatch between WebSocket and HTTP on the same port. I am not sure it would simplify things >
> much to abandon those goals.


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.

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.

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.

cheers













> If the goal was not to interoperate with HTTP at all, it would be much better to use an approach where everything is encrypted. One plausible way to do that would be to restrict the protocol to TLS-only, at which point the nextprotoneg proposal can take care of dispatch without having to involve the HTTP layer. I think this is a plausible option, but many hybi WG members have expressed concern about the performance issues and other barriers to deployment of an all-TLS solution.
>
> Another approach is to invent our own crypto and start with a key exchange. Inventing crypto makes me nervous compared to using something known (such TLS), and might well impose many of the same costs that folks are worried about with TLS.
>
> It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group. We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board.
>
> Regards,
> Maciej
>
>

Received on Tuesday, 7 December 2010 07:32:10 UTC