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

["Joe Hildebrand" <[e-mail]>]

That's been suggested in the past, and likely won't get us to consensus quicker. 

-- 
Joe Hildebrand

On Nov 30, 2010, at 12:13 PM, "John Tamplin" <[e-mail]> wrote:

> On Tue, Nov 30, 2010 at 1:39 PM, Ian Fette (イアンフェッティ) <[e-mail]> wrote:
> So, can we make a decision? CCing Joe and Sal, I would like to see a call for consensus.
> 
> What exactly would we be making a call for consensus on?  It seems there are strong objectors to Adam's proposal.
> 
> I have implemented a slightly earlier version (using AES, different bogus host header, HTTP headers instead of JSON) of Adam's proposal and it seems to work fine.
> 
> I still have concerns about WebSocket traffic to port 80 getting through any non-transparent proxy however, since all of the ones I have seen are configured by default to only allow CONNECT requests to port 443.
> 
> Should we consider initially supporting only port 443?  With all the attacks on unencrypted connections (such as Firesheep making it easy and in the news), it wouldn't be a bad thing to avoid the problem entirely.  That would also solve the attacks Adam saw since the proxy can't decrypt the traffic to be confused by it, and it should make it easier to traverse such proxies since they already work that way to allow HTTPS connections.  We could have ws not check the certificate, while wss does, so ws wouldn't give protection against man-in-the-middle attacks but wouldn't require the servers to have real certificates (they could just use self-signed certs).  If we do this, the details of the handshake are less important -- probably the v03 handshake is fine.
> 
> The downsides would be:
> virtual hosting WebSocket connections requires TLS SNI support, which AFAIK means the only browser with signficant market share that doesn't support it is IE6
> client-side TLS SNI support seems weak (AFAIK, there is no way for a Java client to support it)
> some intermediaries may just block it if they can't filter/audit it
> some configuration overhead on servers
> some CPU overhead (though Google publications have indicated this is very low)
> Is this worth proposing on the group?
> 
> -- 
> John A. Tamplin
> Software Engineer (GWT), Google