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

[Adam Barth <[e-mail]>]

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 (イアンフェッティ) <[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
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>