Re: [hybi] WebSocket, TLS and intermediaries

[Roberto Peon <[e-mail]>]

On Tue, Jul 20, 2010 at 5:01 PM, Maciej Stachowiak <[e-mail]> wrote:

>
> 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.
>


Hear, hear. This is the part about intermediaries that is really terrible.
They ossify the net.
There is another concern w.r.t. intermediaries.
Schools and other institutions will block port 443 if they feel unacceptable
content is flowing over it and they have other means of dealing with it.
I believe that this means that we need an 'authorized proxy' model. No proxy
would be fully transparent (unless it was a reverse proxy representing the
real endpoint), however it should be exceptionally easy to install a policy
allowing the proxy explicitly. It is a hair more annoying for the user than
no proxy, but it gives schools, etc. a way to control the computers that
they own without blocking port 443 for everyone and everything.



>
> 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
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>