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

[Willy Tarreau <[e-mail]>]

Hi Ian,

On Mon, Oct 11, 2010 at 09:04:08PM +0000, Ian Hickson wrote:
> On Mon, 11 Oct 2010, James Graham wrote:
> > 
> > So there is an underlying issue here that I don't understand. It seems 
> > clear to me that Adam and Eric's proposed handshake has a better 
> > security story with regard to cross-protocol attacks than -75, -76, or 
> > any other proposal other than using NPN with TLS. However there seem to 
> > be a number of people who have problems with this proposed handshake to 
> > the extent that they are prepared to forgo the security properties in 
> > order to get something different. In general people seem to be aware 
> > that they are making the security weaker since the arguments are mostly 
> > about how different approaches will probably be good enough in practice 
> > even though they are theoretically inferior.
> > 
> > What I haven't followed is what the problems with the proposal actually 
> > are. I understand that I have likely missed these in other messages, but 
> > it would be helpful if people who believe that the proposed approach, or 
> > aspects of it, are unworkable could summarise the outstanding issues 
> > they see.
> 
> I would like to ask a similar question, but to the people proposing Adam 
> and Eric's latest proposed handshake. What real problem does it solve that 
> NPN with TLS doesn't solve? As you say, it is weaker than NPN with TLS, so 
> why not just go all the way?
> 
> This would have multiple advantages beyond just being more secure, for 
> example we could halve the number of schemes we're introducing, halve the 
> number of handshake implementations on both clients and servers, greatly 
> reduce the testing burden, etc.

And unfortunately prevent content analysis in schools, and be blocked by
default in many enterprises, and probably make virtual hosting impossible,
unless the target resource can be announced in the TLS setup, which I'm
not sure is possible with NPN.

In fact, I think that if the WS work was started, it was to get rid of the
mechanisms relying on long polling. And those mechanisms were invented
because only HTTP passes everywhere. If we propose something which is
not compatible with currently deployed HTTP infrastructures, we'll then
still keep the current mechanisms and have WS proposed as an Nth alternative
for some situations, which will definitely make the situation worse for the
user and for the developer.

That need of compatibility with already deployed HTTP infrastructure seems
to be dismissed too much in this WG in my opinion, and I don't think I'm
wrong to predict a success directly dependant on this compatibility.

Regards,
Willy