- From: Greg Wilkins <gregw@webtide.com>
- Date: Tue, 7 Dec 2010 09:18:00 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Mark Nottingham <mnot@mnot.net>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 7 December 2010 09:07, Maciej Stachowiak <mjs@apple.com> wrote: > > It's worth testing. But GET+Upgrade+Hello requires an extra round trip to set up the connection. There is no extra round trip for GET+Upgrade+Hello as it is proposed. There would be an extra round trip if we want to wait for confirmation from the browser that a server-nonce has been hashed correctly, but this xtra RTT would apply no matter what handshake is used. > 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. Indeed - the protections against the other threat models can be applied equally to either handshake. They are essentially unrelated to CONNECT or GET+Upgrade. >> 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. See the data I just posted to the other thread. High well known ports are no worse than using port 80 and using 443 is not that much better. cheers
Received on Tuesday, 7 December 2010 08:18:33 UTC