Re: [hybi] WebSocket, TLS and intermediaries

[Maciej Stachowiak <[e-mail]>]

On Jul 20, 2010, at 4:29 PM, Mike Belshe wrote:

> 
> 3. Error checking
> A properly written intermediary is also expertly written. So it would be able to prevent protocol exploits that may appear. In addition, these types of intermediaries would be maintained for the purpose of security and thus updated faster than you could hypothetically update client(s) and server(s). While it doesn't eliminate the spread of exploits and malware, it can reduce it. If we are supposed to be as concerned as we are about security, we should also cover the possibility that there may be a security hole in the future (one that we couldn't consider now) and make sure it can be protected. An intermediary can be a part of such a solution, but that also implies we must have intermediaries that can talk WebSockets.
> 
> Let me try to be objective about the tradeoff here:  When everything is encrypted and authenticated at the endpoints, it prevents an intermediary (who's motivations may be different than yours) from taking action.  When data is not encrypted & authenticated, intermediaries, which have different motivations (good or bad) are possible.
> 
> So the sad news is that for every good motivation, there is an equal and opposite bad motivation as a counter argument...

Also, in practice it does not seem to be the case that intermediaries are updated faster than clients or servers. One of the challenges to deploying new protocols or protocol features is old intermediaries that are not updated.

> 
> Actually, if you do that, the browser throws up a huge red box saying "danger".  The MITM will not have a signing cert for a CA trusted by the browser.  So, the cert will be signed by the ISP or other transparent intermediary, which won't match the trusted CA list, and the browser will complain.  Corporations can get around this by forcing a CA cert onto the browser; but that is no longer a transparent intermediary - it was specifically granted permission at the endpoint.  Of course, the user, not knowing what the hell is going on, will click through anyway, think "that's weird", and everything else will still work.

Browsers don't have to accept broken certs for WebSocket with a clickthrough the way many still do for Web sites. I would argue that they should not, because the security consequences of the decision cannot possibly be understood by the typical user.

> 
> BTW - there is another data point here; deployment of WebSockets over port 80 was measured in Chrome to have ~67% success rate today.  Deployment over port 443 (with TLS) has a >95% success rate.  So, if you don't use TLS, then browsers and websites will need to be made more complex to deal with the edge case of WebSockets failing in weird ways due to existing intermediaries which fail, even after the WebSocket handshake.

This point is very important. Building on top of TLS has huge practical benefits. I think this outweighs the desire to more easily build transparent intermediaries. Any mechanism that allows intermediaries without being authorized by either endpoint is by definition a security vulnerability in the protocol.

I think the benefits of TLS also outweigh the "amateur server implementor" argument. I don't think we want to make it easy to implement a security hole.

Regards,
Maciej