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

[Greg Wilkins <[e-mail]>]

On 29 September 2010 09:50, Maciej Stachowiak <[e-mail]> wrote:

>> + Reliance on the browser not treating the 101 response as an error.
>> + The inability to read the ping frame after the 101 response.
>
> The threat model I described involves an attack on integrity, not confidentiality, so these two defenses do no good.
>
> In other words, the threat model is that the attacker sends commands with side effects that it shouldn't be able to, and doesn't care about reading the response.

This would rely on a WS server taking an undesirable side effect on
the basis of a partially negotiated WS connection.
If such a server was written, surely it would be vulnerable to any WS
client and thus this is not a cross protocol issue, just
a poorly written server.   More importantly, is there anything about a
raw HTTP request that cannot be done in a normal WS upgrade request
that is likely to trigger such a side effect?


>> + The inability to send a pong frame
>
> I don't think this one is true. Why couldn't you include it in an HTTP message body? Your original proposal does nothing to prevent this. Adding a server-provided nonce to the ping and requiring it to appear in some form in the pong does add some protection, but only as strong as the server's (possibly ad-hoc) choice of RNG.

It is conceivable that some HTTP requests might also be valid WS
frames.   However, as HTTP sent from the server will start with
HTTP/1.1 XXX reason, then only very contrived frames could be sent.
The first two bytes of a ping frame carrying a 16 byte hash are STX
DLE, and certainly not a valid HTTP response and an invalid method
name in a HTTP request.

So I stand by my claim that a pong frame cannot be sent by a HTTP
client, but perhaps some very contrived framed could be (see below).



>> + The inability to provide credentials (not otherwise available to
>> normal HTTP) to access authorized content
>
> Network position is itself effectively a credential. Some servers are only protected by a firewall. This is common not only in enterprise scenarios but also with many consumer devices that offer Web-based configuration. Browsers generally consider it their responsibility not to expand the attack surface in such cases.

If the network is the only credential needed, then the compromised
browser will eventually have a WS client and thus this is not a cross
protocol issue.     There is nothing about WS that is different than
just HTTP in this regard and we would have to hope that the browser
origin policy would protect both HTTP and WS from such poorly
authenticated services being attacked by local compromised clients.
Unfortunately many such environments probably have XSS vulnerabilities
as well, so the origin model can be subverted, but this is an existing
risk and there is no additional risk introduced by WS here.



>> + The inability to make a WS server send unauthorized content as
>> valid WS frames
>
> Not relevant to the threat model. Again, because the threat is an attack on integrity, not confidentiality.
>> + The inability to provide credentials (not otherwise available to
>> normal HTTP) that might trigger server side effects
>
> Not relevant to the threat model, which is existing HTTP functionality being used to attack WebSocket servers.

They are still defences against other cross protocol attacks, hence I
listed should be listed as part of the defences.




>> + The inability to send a WS frame from a HTTP client that might
>> trigger server side effect.
>
> I don't think this is true. What stops you from sending the bytes of a WS frame from an in-browser HTTP client?

It is indeed possible that some HTTP messages may indeed be valid WS
frames, and I think that perhaps we
need to do some further consideration of the framing mechanism to make
sure that ASCII method names do not
become legal frame headers.

While the opcode is mostly 0x00, the -76 and -00 are pretty safe from
HTTP methods looking like WS frames.
But as more opcodes and RSV bytes are allocated, then there is a
slight risk that a meaningful WS framing might be
comprised entirely of ASCII characters that could be put into a HTTP
method name.

So at this stage, I think I should water down this point.  There is
not an inability to send a legal WS frame from a HTTP client, but
there is the inability to send an arbitrary legal WS frame but some
possibility that some highly contrived WS might be sent.

Note that this was no different to -76, where a hashed nonce could
also be all ascii characters.

If we are concerned about this level of defence not being sufficient,
then we may need to revisit the framing protocol to perhaps make sure
that the header cannot be represented by a HTTP method name or
HTTP/1.1 response.



>> + That even if all of the above could be subverted, the attacker
>> would only have a capability (to talk WS), that we plan to have widely
>> available within the browser.
>
> WebSocket itself will not send any frames until the handshake is complete, but HTTP sends the body along with the headers. So it's not the same. You can't count on browser-side checking of the server response to protect WS servers from HTTP clients.

I don't think you have understood my point.   Let's say that we can
subvert a HTTP client so that it passes the WS handshake, so we know
have a WS connection wired to a HTTP client.   Does that now give us
any capabilities that represent a threat that we would not have if we
were using a WS client?

Actually to answer my own question, a HTTP message that is contrived
to look like a WS frame will be able to have the opcode and RSV bits
set by the caller, which otherwise is not the case for WS clients.  So
this last defence is weaker than I represented, but that's why we have
defence in depth.   Again, we might want to revisit framing to ensure
that HTTP methods cannot form valid WS headers.

Excellent - this exchange has finally been productive and I think we
have indeed identified some weaknesses (albeit already existing in
-76) that may need to be strengthened if we suspect that a HTTP client
could somehow get past the other handshake defences.

But so far, there has been no indication that my proposal to change
the nonce encoding and to frame the hashes as WS packets has weakened
the defences.  I believe that the analysis we are doing is still
showing that it is at least as secure as -76.

regards







regards