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

[Ian Fette (イアンフェッティ) <[e-mail]>]

Willy,

People are welcome to use the null cipher suite with TLS.

On Mon, Oct 11, 2010 at 2:12 PM, Willy Tarreau <[e-mail]> wrote:

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