Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

[Maciej Stachowiak <[e-mail]>]

On Jul 25, 2010, at 9:00 PM, Mike Belshe wrote:

> On Sun, Jul 25, 2010 at 6:45 PM, Maciej Stachowiak <[e-mail]> wrote:
> 
> On Jul 25, 2010, at 5:07 PM, Greg Wilkins wrote:
> 
> > Mike,
> >
> > thanks for translating the intent of the browser dudes and explaining why they are so concerned about this issue.
> >
> > I am certainly not opposed to taking measures to ensure that websocket is not a easy-touch for attackers to use against other protocols and also to make it more robust against attacks itself.    I think these are reasonable requirements.
> >
> > However, I still don't see why the only acceptable solution to these concerns has to be a rigid non compliant HTTP handshake with space counting and unframed bytes on the wire?
> >
> > I think this WG has to clearly accept the concerns of browser vendors and make sure that the requirements clearly capture them.     But in return, the browser vendors have to accept that there is more than one way to skin a cat, and perhaps we can consider alternative solutions than the one that is currently causing significant objections and real world problems.
> 
> From the perspective of a browser implementor:
> 
> (1) I definitely don't think that the current draft WebSocket protocol is the only possible effective defense against cross-protocol attacks.
> (2) If anything, I'm not sure that it is effective enough.
> (3) I believe there have been proposals made that are more effective at mitigating cross-protocol attacks than the current draft, such as the TLS next protocol mechanism. However, TLS-only has its own downsides.
> 
> Adam has also suggested encrypting the channel.  Even without TLS, this would go a long way toward preventing attackers from sending particular byte patterns over the wire, and could probably be done without adding round-trips.

I have a lot of trust in Adam on these kinds of issues, but I'll have to see the details to judge the security.

One question in my mind: would this design plausibly work on a port shared with a non-SSL Web server? Would it be able to go through non-SSL proxies? The inability to do these things is one of the largest downsides of TLS-only. Another downside is the need for a cert, but I imagine there is some way to use TLS without requiring certs.

Regards,
Maciej