Re: [hybi] Handshake was: The WebSocket protocol issues.

[Ian Hickson <[e-mail]>]

On Sun, 26 Sep 2010, Maciej Stachowiak wrote:
> 
> As I have thought about these issues, I am increasingly convinced that 
> an NPN-style solution is much more robust. Attempting to make a TLS 
> connection to a vanilla HTTP server, or an HTTPS server that does not 
> understand NPN, will reject the connection at a very low level, greatly 
> limiting the potential for shenanigans. Browser clients in general do 
> not offer APIs that would allow a Web attacker any control of the 
> outgoing TLS handshake, and the TLS layer would fail a bad connection 
> before server software even had the opportunity to make a mistake. This 
> approach seems much more robust to me. Rather than just barely being 
> secure, it fails hard before the attacker can even do anything tricky. I 
> think it is much likely there would be future attacks. I hope the WG 
> strongly considers the NPN approach, despite the costs and challenges 
> imposed by using TLS.

I agree. There were two main advantages to the handshake I had specced: 
first, it would allow us to move fast and iterate, with browsers all being 
able to have WebSocket client support in the current cycle, and second, it 
would be easy to implement for amateur Web authors.

Since we have missed this implementation cycle, and since the framing of 
the protocol is going to support elaborate features such as fragmentation, 
multiple channels, and so forth, to the point where amateur deployments 
are essentially required to use a library and can't realistically be 
expected to write their own servers, I really see no reason at this point 
to not always require TLS and to use an NPN-style forced protocol switch.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'