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

Sorry for the over-brief response. I was assuming in the world of an NPN
handshake that wss:// would use a strong cipher suite and check that the
certificate is valid, and that in the world of ws:// the NULL cipher suite
would be used, and the certificate would not be checked for validity (e.g.
self-signed cert would be fine.)

-Ian

2010/10/11 Adam Barth <ietf@adambarth.com>

> Or just use the ws version that doesn't check certificates (as opposed
> to the wss version that does).
>
> Adam
>
>
> 2010/10/11 Ian Fette (イアンフェッティ) <ifette@google.com>:
> > Willy,
> > People are welcome to use the null cipher suite with TLS.
> >
> > On Mon, Oct 11, 2010 at 2:12 PM, Willy Tarreau <w@1wt.eu> 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
> >> hybi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> >
>