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

[Adam Barth <[e-mail]>]

Your email appears to proceed from the assumption that the current
handshake is sufficiently robust to cross-protocol attacks.  That
might well be true.  However, I don't think we have any reasonable
assurance that it is true.  If we can't have reasonable assurance of
the security of the -76 handshake, then we certainly cannot have such
assurance about your handshake since it is strictly weaker.

On the other hand, we can be reasonably assured that the TLS+NPN
handshake resists cross-protocol attacks.  I provided a security
argument to that effect in an email a while ago.  No one has provided
a similarly detailed security analysis of the -76 handshake or of the
handshake that you propose.

Adam


On Sun, Sep 26, 2010 at 11:16 PM, Greg Wilkins <[e-mail]> wrote:
> On 27 September 2010 11:35, Adam Barth <[e-mail]> wrote:
>> Browser also protect intranet servers which use connectivity as their
>> sole means of authentication/authorization.
>
> True.
>
> So does the presence of WS capability in the browser and/or server
> provide any additional capability to exploit such servers?
>
> If so, do the measures in the current and proposed handshakes help in
> any significant way?
>
> If not, is there something that we need to do to explicitly protect
> port ranges etc in the same way that browsers currently do for XHR?
>
>
>> The existing HTTP mechanisms exposed to untrusted content in browser
>> already respects these security invariants.  In adding new network
>> APIs, browser wish to continue to maintain these invariants.
>
> Excellent and both the requirements document and all recent versions
> of the specification have included text to the effect that the
> existing browser security model will be used.
>
> Maybe that text needs clarification, but nobody has suggested watering
> it down in any way.
>
>
>
>>> I think that any server that "performs any side effects in response to
>>> messages from the client" will have a security vulnerability if they
>>> do not correctly check the authentication and authorization of the
>>> client.
>>
>> This is not an accurate understanding of the security invariants
>> browsers seek to maintain.
>
> I was not attempting to describe the security invariants that a
> browser seeks to maintain.
>
> I was making the observation that a server that performs side effects
> on the basis of unauthenticated requests will by definition have a
> security issue.   The ability to trigger that issue from a cross
> protocol attack is essentially irrelevant if we are proposing the wide
> spread deployment of a same protocol mechanism that can trigger the
> same side effects.
>
>
>>> Eventually most browsers will have WS available to the
>>> javascript, so a server that is so vulnerable will be able to be
>>> exploited just with WS instead of trying to trick HTTP.
>>
>> Browser seek to protect servers that have never heard of WebSockets
>> and have no interest in these newer technologies.  From that
>> perspective, it's important to compare the security invariants of the
>> browser before and after introducing WebSockets.  We need to study any
>> change in these invariants to make sure they don't introduce security
>> vulnerabilities in existing servers.  This is a prerequisite for
>> exposing the WebSocket API to untrusted content in the browser.
>
> Which is precisely why I have been advocating that we study the impact
> of the current handshake and proposed changes.
>
> We need to discuss what type of byte sequences can a compromised WS
> capable browser generate that a HTTP capable browser cannot? Are any
> of these types of sequences a threat to WS unaware servers?   Does the
> space counting and unframed bytes help in any way?
>
> I have suggested that the defence in depth of Sec-headers, nonce
> generation, handshake sequence requirements and normal web
> authentication/authorization should limit the byte sequence that can
> be generated to nothing that is more harmful that what can already
> been generated.
>
> All I have asked is if you have done any study that indicates that
> suggests that space counting and unframed data provide any additional
> meaningful security?
>
> regards
>