Re: [hybi] Extensibility mechanisms?

[Greg Wilkins <[e-mail]>]

On 22 July 2010 16:21, Adam Barth <[e-mail]> wrote:

> On Wed, Jul 21, 2010 at 11:04 PM, Greg Wilkins <[e-mail]> wrote:
> > On 22 July 2010 14:40, Adam Barth <[e-mail]> wrote:
> >> The more I read on this list, the more I think that folks here don't
> >> understand the requirements on the protocol, especially the security
> >> requirements.  That's understandable if you haven't worked extensively
> >> with the browser security model.  Fortunately, Ian is an expert on
> >> these topics and has more time to reply to this list than I do.  I'll
> >> try to address some of the confusion in this email, but I might not be
> >> able to answer all the followup questions.
> >
> > I don't think there is any specific lack of understanding of protocol
> > requirements in this WG. However there may be some disagreement with what
> > those requirements are.
> >
> > It is great that you respect Ian's opinion, but I'm afraid he has failed
> to
> > convince many in this WG of the need for some of the more esoterica
> > "features" in the -76 draft.
> >
> > Take the security issue for example.  There was a concern that websocket
> > could be used in combination with an injectable server to spoof it to
> > generate a legal websocket handshake response (what good that would do
> > anybody I don't really know, but let's assume that it is evil and
> dangerous
> > and that the injectable server cannot be exploited in other ways).    In
> > response to that concern, this list pretty much agreed that we should
> > include a random token in the handshake that was generated after the URL
> had
> > been passed to the javascript websocket API.  Since this token would be
> > unpredictable, then it would be impossible for anybody to craft a URL
> that
> > would cause that token to be injected in a response. Problem solved.
>
> I don't think these issues are as simple as you seem to believe.
> Security is rarely as simple as blithely tossing in a nonce and hoping
> for the best.  Also, I'm skeptical about using the work "impossible"
> in the context of what an attacker can and cannot do.  It smacks of
> the kind of hubris that leads folks to a false sense of security.
>

Adam,

I am not claiming that a random nonce is a solution to all the security
problems.
But I believe it is a very good solution to the specific concern expressed
that an injectable HTTP server might be able to be tricked into sending and
acceptable websocket hand shake response.

If the token is unpredictable and generated after the URL is passed, then I
do believe that we can say that it is impossible for a URL to be crafted
that will inject that token into a response. Of course "unpredictable" is a
relative measure, but I think good server developers are already on top of
that one when it comes to the generation of session IDs and similar
(although it is surprising how difficult that is).

Conversely, I think the count spaces and divide results is exactly the type
of algorithm that can have unexpected numeric effects that might result in
the number of truly random bits being significantly reduced and this more
predictable, specially if the same random generator(algorithm) is used to
produce the numbers and to place the spaces.  It would not surprise me if
such an algorithm significantly reduced the search space.

You seem to essentially be saying that you don't understand the
> rationale for all the cross-protocol mitigations in the current
> handshake.  I'm not sure I understand them all either.
>

Using a pseudo secure algorithm that has not been subjected to any rigorous
analysis is not going to help either.


> The essential problem is that we don't have a science of
> cross-protocol attacks in the same way we have a science of
> cryptographic primitives in network protocols.  It seems likely that
> Ian has layered these mitigations into the handshake as defense in
> depth.  Without a way to evaluate cross-protocol attacks, it seems
> prudent to use a bunch of mitigations and hope that at least one of
> them saves us in any given situation.
>

I'm all for defence in depth.
Note that the random token is already the second line of defence as you
firstly need a scriptable browser, that can talk to an injectable server.

Can you tell me that the count spaces algorithm really adds another layer of
defence? or does it just make the random nonce more guessable?


As an aside, that's why I prefer the TLS+NPN approach.  It's a simple
> mechanism that I can convince myself resists cross-protocol attacks.
> Moreover, I understand exactly what role each piece of the protocol is
> playing, which means we don't need to layer together a string of
> half-defenses and hope the holes in the cheese don't align.
>

Similarly a random nonce is a simple mechanism, which good developers will
understand and know that they need to provide sufficient random bits that
are unpredictable and protected from discovery by the javascript client.

regards