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

[Greg Wilkins <[e-mail]>]

Adam,

Your email appears to proceed from the assumption that I'm arguing
against a TLS+NPN solution.   I'm am not and fully support efforts to
propose that as an alternative (and potentially only) websocket
handshake.

With regards to the HTTP upgrade handshake, I am trying to get this WG
to participate in exactly the analysis that you suggest is lacking so
that we may have some reasoned assurance.  Telling us that there are
some things that we have not thought of, while not even giving a vague
suggestion as to what they might be is hardly helpful.

I have tried to put the discussion in terms of capabilities that WS
might add to a browser, specifically are we enabling the transmission
of any hazardous bytes sequences to unsuspecting servers?    Both the
-02 draft has several defences that stop a compromised client from
being able to send the required structure of bytes and from knowing
what bytes they should send even if they could.   I do not believe
that my proposed handshake changes have weakened these defences in any
way and all you have been able to say to the contrary is that they
might have.

Well I can say the same: TLS might be vulnerable to man in the middle
attacks and recent experience proves that to be plausible. But that is
not an real argument against TLS, just the same as your suggestion
that my proposal might have weakened the handshake.

regards







On 27 September 2010 16:26, Adam Barth <[e-mail]> wrote:
> 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
>>
>