Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

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.

> But when Ian codified this general agreement in the specification, he
> adorned it with several extra "features".  He split the random number up and
> added a pseudo secure algorithm involving count spaces, taking away the
> number you first thought of and divide by your grandmothers birthday.  This
> is totally unnecessary complexity and confusion because the random token
> would be generated after any client had the chance to inject the URL, so no
> further protection is needed from injection.  It is another silly example of
> being fixated on the exact bytes of a message rather than the semantics that
> the message is carrying.
>
> Ian further "enhanced" the solution by sending the random token, not in
> headers as had been discussed, but in extra bytes that comply neither with
> HTTP nor with websocket framing.  The motivation for these bytes is
> apparently to fast fail if there in an intermediary that does not support
> websocket.   However, among many other problems with this mechanism, it has
> now been shown that this mechanism slow fails with an intermediary that
> would support websocket if not for the extra bytes.
>
> Fast fail is indeed a very desirable requirement (although not always
> achievable).   Protection from injection is also a desirable requirement.
> But there was no need to mix the solution to these two requirements into a
> single solution (with extra pseudo security).  If Ian had simply added the
> random token as a header as had been discussed and widely accepted, then we
> would no longer be talking about it.
>
> He could also have raised the fast fail requirement (ideally by proposing it
> as an addition to the requirements document), and then we could be using the
> considerable experience available in this WG (and elsewhere) to come up with
> the best solution to that problem.
>
> We will only make progress is we methodically break down requirements and
> consider multiple solutions.   Intransigent insistence of the first
> one-size-fits-all "solution" does not help at all.

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.

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.

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.

Adam