Subject: Re: [hybi] proposed masking

From: John Tamplin <[email-masked]>
Date: Thu, 6 Jan 2011 21:38:30 -0500

Ok, I understand your complaint about unlike SSL and other wrappers,
the proposed masking means an observer can't tell frame boundaries
without unmasking first.  I am still not sure that is such a big deal
considering the simplicity of the proposed masking relative to
interpreting the framing anyway, but here is another attempt to
satisfy all concerned:

Since I don't want to renogiate anything we have already agreed in the
base framing, that
means that Extension Data can only have a non-zero length if we
negotiate an extension, so that means we can't have masking be the
default and define a new extension later to remove it.

My proposal:
1) Define a new extension "clientmask" in the base spec, which
   specifies that client->server masking is present.  An optional
   parameter "type" specifies the type of masking, and if not
   present defaults to "hmac-sha1".
 (this leave open the option
  of defining new masking methods in the future).
2) Any clients which make WebSocket connections at the
   request of untrusted code or entities and do not know for
   certain that the entire path to the ultimate server is trusted
   MUST request the clientmask extension and MUST fail the
   connection if the server does not accept the extension.
3) Any servers (or intermediaries acting as servers to the client)
   accepting a connection from an untrusted source MUST NOT
   accept a connection which does not request the clientmask
   extension.  A server accepting a connection from a client that
   is known to transit only trusted networks MAY accept
   connections which do not request the clientmask extension.
   A server which allows connections without the clientmask
   extension SHOULD default to no trusted networks and be
   configurable as to which networks are allowed to connect
   without the clientmask extension.
4) If the clientmask extension is negotiated, the first n bytes of
   the extension data of client-server frames is a per-frame key
   defined by the masking type, and the remainder of the payload
   (including any further bytes of extension data and application
   data) are masked as defined by the masking type.
5) For clientmask type of "hmac-sha1", the per-frame key length
   shall be 4 bytes, and the remainder of the frame shall be masked
   according to the following algorithm:

     Let client-nonce and server-nonce be the respective nonces
     exchanged during the handshake.  Let uid be a 20-byte constant
    defined in the standard, and per-frame-key be the masking key
    read from the extension data.

    // computed once during the handshake
    sessionKey = HMAC-SHA1(uid, client-nonce || server-nonce);

    for (int blockStart = 0; blockStart < remainingLength; blockStart += 20) {
      mask = HMAC-SHA1(sessionKey, per-frame-key || blockStart);
      for (int i = 0; i < 20 && blockStart + i < remainingLength; ++i) {
         remainingPayload[blockStart + i] ^= mask[i];
      }
    }

    The same operation is performed for masking and unmasking.

The intent of #1 is to conform to requirements established in the
current framing, in that Extension Data can only be used if an
extension is negotiated, as well as allowing the masking algorithm
to be refined in the future without defining a new extension.

The intent of #2 & #3 is to allow the use-cases that have been
brought up, where the safety provided by masking is not needed.

--
John A. Tamplin
Software Engineer (GWT), Google

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 7 Jan 2011 11:13:02 +0800

>     The same operation is performed for masking and unmasking.

Changing the mask continuously is only necessary if the recipient can get the sender to alter what they send mid-message.  Whether that is going to be necessary depends on the interface provided to the sender.

If a browser only offers an API that accepts entire frames for sending, the sender doesn't get a chance to modify frame contents on the fly and this algorithm is going to be overkill.  I don't know what the impact would be, but it does seem like a saving worth considering.  Maybe it's only an option, but the client (browser) is in the best position to make that determination.

That is:

      sessionKey = HMAC(uid, client-nonce || server-nonce);
      mask = HMAC(sessionKey, per-frame-key);
      for (int i = 0; i < length; ++i) {
         payload[i%HMAC_LEN] ^= mask[i%HMAC_LEN];
      }

If the per-frame-key is changed on each frame, then streaming can still be done with this mechanism, you just have to buffer an entire frame before sending it and use continuations.

--Martin

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 7 Jan 2011 06:52:44 +0100

On Mon, Dec 27, 2010 at 04:30:43PM -0800, Maciej Stachowiak wrote:
> > But I'm strongly against masking the framing itself.  Their is
> > absolutely no reason for it other than to prevent the possibility of
> > making it optional.
> 
> That's not right. One reason for masking the framing is to make it impossible for hostile browser-hosted hosted code to pre-generate valid-looking frames. If you don't mask framing, then it is trivial to create valid-looking frames, even if the contents are scrambled. Depending on circumstances, this could still be a dangerous attack on integrity.

No Maciej, it's not "trivial" to do that because if you look at the framing,
very little of it is directly controlled by the application. As I suggested
in another mail, if you use RSV4 to indicate masking is used and put the
random key in extension data, that leaves you with :
  - first byte with MORE|RSV1|RSV2|RSV3|OPCODE = 1|XXX|OPCODE
  - second byte with RSV4|LENGTH = 1|LENGTH
  - 3rd-4th bytes corresponding to the low part of the payload length,
    only if previous byte is 0xFE/0xFF
  - 5-10th bytes corresponding to the high part of the payload length
    only if 2nd byte is 0xFF
  - random key the size of the payload length
  - application data

The only controllable part here in which you might put an HTTP request is
the key length. But even in order to write an HTTP/0.9 "GET /\n", you have
to forge a message that is 0x54202F0A4745 bytes long, or 92 TeraBytes long.
And if you need to start it at the beginning of a line, it becomes
0x4554202F0A0A47 which is 19 PetaBytes. By the time we get browsers able to
construct that large messages, we won't bother anymore about the broken
intermediaries.

That's why I'm really considering masking the payload safe enough with
regards to the risk we're trying to cover.

Regards,
Willy

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 7 Jan 2011 14:02:16 +0800

> construct that large messages, we won't bother anymore about the broken

If you don't care about the noise in the header, you can construct a request that contains that 6 byte message in the body by sending a message of 6*2^k bytes (for 8 bits of random key, that's only 1.5k), not allowing for overlapping.

After all you have to have the initial noise bytes ignored, what's another 10 or so...

::)

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 7 Jan 2011 07:15:26 +0100

> If you don't care about the noise in the header, you can construct a request that contains that 6 byte message in the body by sending a message of 6*2^k bytes (for 8 bits of random key, that's only…

The 8 bit random key could not be used with 1.5k, it would be a 16 bit one,
resulting in 6*2^16 => too large for this key size too, need a 63-bit one,
resulting now in 6*2^63 bytes to forge the message. That was my point :-)

Willy

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 7 Jan 2011 10:55:33 +0100

>   according to the following algorithm:

John,

oops I missed this proposal before sending my own in another thread.

I think your proposal is substantially the same as mine.  A few notes:

1. I'm still dubious about the benefit of specifying a masking type
other than XORing of a random per frame key. Any algorithm chosen
appears vulnerable to accusations of "too expensive for
client/intermediary/server of type X".
2. I'm happy either to have a default extension (as per my proposal)
or to require browsers to use the clientmask extension.  Whatever the
browser folks think is simplest.
3. I think this one will be hard to implement/enforce.  But maybe some
verbiage recommending servers consider using clientmask if there is
doubt about the path.
4. Perfect!
5. I really do not see the need for mixing in the nonces, thus making
the masking non self describing and making it impossible to decode
frames from mid stream.  It strikes me as  overkill and with
significant consequences.

Other than the masking algorithm, I think we are in agreement.
Your masking algorithm is not a total show stopper for me, but I fear
that specifying any moderately complex masking algorithm is just going
the raise the hackles of those that are entirely unconvinced that
masking is needed in the first place.

To merge the two threads, my proposal was:

 + The specification is updated so that extensions can use extension
data with out using a reserved bit
 + A "masking" extension is defined that includes a 32bit masking key
in the extension data of each frame.   The key should be
unpredictable, but the specification will not define how it is
generated.
+ The masking key is applied with XOR to all extension data following the key.
+ The masking key is applied with XOR to all normal payload.
+ The masking extension is the default extension, so that if no
extensions are negotiated it will be used from client->server
+ If other extensions are negotiated, then "masking" will need to be
explicitly negotiated in the list of extensions.
+ We also define the "identity" extension, which is a do nothing
extension.  If both ends negotiate to use the "identity" extension
only, then only the do nothing extension is applied and masking is not
used.
+ Browsers or any client that executes 3rd party code, MUST NOT accept
connections with identity only extension.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 06:20:09 -0800

> regards to the risk we're trying to cover.

Willy, I think we're talking past each other. The threat model I'm talking about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in the browser will effectively let you send any bytes you want as the payload. You seem to be talking about the opposite threat model, where WebSocket APIs in the browser, to attack HTTP.

These are completely separate threat models, and both are important to consider.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 06:28:07 -0800

I have several objections to this proposal:

1) The idea of an extension that is, in most circumstances, mandatory for both clients and servers seems silly. If the normal use case is that you always request it from the other endpoint, and refuse the connection if the other endpoint won't use it, then it's not an extension.

2) Designing things this way creates more risk of bugs leading to total security failure.

3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services.

4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of the masking (perhaps in minor or edge case ways) to make it easier to later address a totally unproven use case.

Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise. Now I feel that GET+Upgrade advocates are incrementally chipping away at the effectiveness of the masking. Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT handshake idea if we can at least have effective masking. I don't think this ratchet method is an effective or fair way to negotiate agreement.

Regards,
Maciej

On Jan 6, 2011, at 6:38 PM, John Tamplin wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Dave Cridland <[email-masked]>
Date: Fri, 07 Jan 2011 14:58:00 +0000

On Fri Jan  7 14:28:07 2011, Maciej Stachowiak wrote:
> 3) Some decent technical reasons have been given for why the  
> framing should be masked as well, for example, when considering the  
> threat model of using HTTP APIs in the browser to attack WebSocket  
> services.

Hmmmph. If you can mimic any data as an HTTP client, then by  
inference you can mimic any masking, surely? The trick, then has to  
be to use restricted features like the Sec-* headers to defeat this  
attack at the handshake level, which we had way back when.

> 4) I still haven't seen evidence of a non-hypothetical use case for  
> removing masking, so I don't think we should warp the design around  
> the possibility. This proposal weakens the effectiveness of the  
> masking (perhaps in minor or edge case ways) to make it easier to  
> later address a totally unproven use case.

I still haven't seen evidence of a non-hypothetical case where  
masking is required.

> Combining masking with GET+Upgrade (instead of a potentially more  
> robust initial handshake) was already a compromise. Now I feel that  
> GET+Upgrade advocates are incrementally chipping away at the  
> effectiveness of the masking. Meanwhile, CONNECT advocates have  
> largely agreed to let go of the CONNECT handshake idea if we can at  
> least have effective masking. I don't think this ratchet method is  
> an effective or fair way to negotiate agreement.

CONNECT on its own fails because it is no longer correct HTTP.  
Pretending it is doesn't help - it breaks end-to-end transparency.

Upgrade on its own has hypothetical - but reasonable - security  
arguments against it. However, in its favour, technologies like CORS  
should "just work", for instance.

So, quite obviously, neither of those two options on their own work.

Would the browser folk be interested in running an experiment to see  
if an Upgrade+CONNECT would work as intended? Would Google be willing  
to use their advertising network for such an experiment? If so, we  
could actually run an experiment that tested each proposal, and then  
for any where no attacks where found, we could select based purely on  
efficiency and correctness.

Basing our decision making on hypothetical vulnerabilities which have  
been shown to be at least sufficiently rare as to not have been found  
seems like a poor course of action.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 7 Jan 2011 16:03:55 +0100

> 1) The idea of an extension that is, in most circumstances, mandatory for both clients and servers seems silly. If the normal use case is that you always request it from the other endpoint, and ref…

I don't think you can say the normal use-case will always use masking.
 Sure it will for the browser, but it may be a very normal use-case
for the the connection to enter a data centre via a web-socket aware
aggregator that forwards the messages without masking to the
application server.     So from the server point of view, the normal
use-case could be without masking.

> 2) Designing things this way creates more risk of bugs leading to total security failure.

that's very subjective.  I think that masking framing will result in
more bugs, specially with partially received frames.

> 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket s…

I do not think that threat has been well explained or accepted, nor is
it the primary target of masking.  Specifically I've not yet seen a
credible explanation of how a HTTP API could generate the required
headers to get past the websockets expectations of the initial upgrade
request.   I don't want to dismiss this vulnerability out of hand, but
I would like to see more detail about it and to consider if there are
other mitigations we could do that would not impede the progress we
were making on masking.

> 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of t…

Unfortunately there are some that see the hypothetical risk of these
intermediaries as warping the design with the introduction of masking.

Beside, there have been many use-case presented (eg the aggregator
above) that would benefit from no masking.  I know you think that
masking is cheap - and it may be in the client, but there are many
opinions on the intermediary/server side that are concerned about the
cost of masking and thus there is a drive to have it as simple and
cheap as possible, if not optional.

> Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise. Now I feel that GET+Upgrade advocates are incrementally chipping away at the ef…

I don't think that is a fair or productive characterisation.    I
could equally say that masking advocates are incrementally increasing
the scope and complexity of masking from the simple prevention of
clear text originally proposed and adding new unproven hypothetical
vulnerabilities - which would also be neither fair or productive.

There is no benefit in having masking unless it is seen to be
effective, so it is in nobodies interests to chip away at the
effectiveness of masking.    I truly do not understand why having the
payload XOR's with a random per frame key will not be effective at
preventing attackers sending clear text.  Nor do I understand why
having masking as an extension reduces it's effectiveness in any way.

I get it that you'd greatly prefer masking to not be an extension, but
in the spirit of compromise, what aspect of masking as an extension is
a show stopper for you?

regards

---

From: "Alexander Philippou" <[email-masked]>
Date: Fri, 7 Jan 2011 18:01:37 +0200

> 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of t…

One large use case is non-browser client systems. I don't see how masking will be useful to them. Masking seems to be protecting against vulnerabilities that affect only browser client systems. Unless there is evidence that these protection mechanisms have a universal usefulness, I would strongly support a design that keeps them as an optional extension.

Alexander

---

From: John Tamplin <[email-masked]>
Date: Fri, 7 Jan 2011 11:06:20 -0500

On Fri, Jan 7, 2011 at 9:58 AM, Dave Cridland <[email-masked]> wrote:
> Would the browser folk be interested in running an experiment to see if an
> Upgrade+CONNECT would work as intended? Would Google be willing to use their
> advertising network for such an experiment? If so, we could actually run an
> experiment that tested each proposal, and then for any where no attacks
> where found, we could select based purely on efficiency and correctness.

The question about Google's participation is above my pay grade, but
assuming the answer to both of the above are yes, are we really
willing to put WebSockets on hold for 6 months or more while an
experiment is crafted, conducted, and analyzed?

---

From: Dave Cridland <[email-masked]>
Date: Fri, 07 Jan 2011 16:39:01 +0000

On Fri Jan  7 16:01:37 2011, Alexander Philippou wrote:
> One large use case is non-browser client systems. I don't see how  
> masking will be useful to them. Masking seems to be protecting  
> against vulnerabilities that affect only browser client systems.

No, not really. It's a vulnerability caused by the compound issue of  
vulnerable intermediaries hypothetically existing, plus downloadable  
code. So it's not "browser client systems" that are vulnerable, it's  
intermediaries in front of browsers which have Flash, Java, or  
WebSockets enabled.

Dave.

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 7 Jan 2011 18:38:52 +0100

On 1/7/11 3:28 PM, Maciej Stachowiak wrote:
> Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise.
Indeed it is a compromise for both the sides.
But it is a compromise that has been largely accepted by people in the poll.
No other proposals so far has received so large consensus.

/Sal

-- 
Salvatore Loreto
www.sloreto.com

> Now I feel that GET+Upgrade advocates are incrementally chipping away at the effectiveness of the masking. Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT handshake idea if we can at least have effective masking. I don't think this ratchet method is an effective or fair way to negotiate agreement.
>
> Regards,
> Maciej
>

---

From: "Alexander Philippou" <[email-masked]>
Date: Fri, 7 Jan 2011 19:54:53 +0200

> No, not really. It's a vulnerability caused by the compound issue of vulnerable intermediaries hypothetically existing, plus downloadable code. So it's not "browser client systems" that are vulnerable, it's intermediaries in front of browsers which have Flash, Java, or WebSockets enabled.

Right. So I don't see what type of protection masking will offer to a "non-browser client system" that consists of non-browser clients, the servers hosting the services that these clients access, and their intermediaries. In this case both sides are tightly controlled and no arbitrary code can be downloaded or run. I understand the vulnerabilities when browsers are involved but don't see what is gained by masking when there are no browsers in the picture. If WebSockets is also to be for clients other than browsers (or more generally when downloadable code is involved) then my opinion is that masking should either be justified for them too or be made optional.

Alexander

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 09:58:51 -0800

On Jan 7, 2011, at 6:58 AM, Dave Cridland wrote:

> Hmmmph. If you can mimic any data as an HTTP client, then by inference you can mimic any masking, surely?

No. If the correct mask includes an unpredictable string sent by the server, then it's not possible to mimic it because the client can't compute the correct mask.

This is actually better than Sec-* headers, because if the server does the check in a buggy way, it won't be able to read from clients at all in the normal case.

> The trick, then has to be to use restricted features like the Sec-* headers to defeat this attack at the handshake level, which we had way back when.
> 
> I still haven't seen evidence of a non-hypothetical case where masking is required.
> 
> CONNECT on its own fails because it is no longer correct HTTP. Pretending it is doesn't help - it breaks end-to-end transparency.
> 
> Upgrade on its own has hypothetical - but reasonable - security arguments against it. However, in its favour, technologies like CORS should "just work", for instance.
> 
> Would the browser folk be interested in running an experiment to see if an Upgrade+CONNECT would work as intended? Would Google be willing to use their advertising network for such an experiment? If so, we could actually run an experiment that tested each proposal, and then for any where no attacks where found, we could select based purely on efficiency and correctness.

I like your Upgrade+CONNECT proposal, and have explicitly supported it in the straw poll thread.

However, even with Upgrade+CONNECT, I would still be in favor of having masking.

> Basing our decision making on hypothetical vulnerabilities which have been shown to be at least sufficiently rare as to not have been found seems like a poor course of action.

>From the browser vendor point of view, if we widely deploy a technology in the browser, lots of websites adopt it, and then a serious security vulnerability is found, the cost is huge. It's extremely difficult to quickly deploy security updates to a lot of users, even more so when this will break their favorite websites. In the meantime, the tech press sows fear and panic.

Since we are designing a new protocol, we are not constrained by legacy yet, and can do better than the historical level of security on the Web. We can set a higher standard than "can't find a fully working exploit today through armchair reasoning" and produce a design that is likely to be robust against a wide variety of threat models.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 10:05:50 -0800

> use-case could be without masking.

I put much more priority on what happens on the public Internet than what happens inside the data center, on a private network. The security of the Internet can't be subordinated to convenience of communication on private networks where security is not as much an issue. Designing "low security mode" into protocols for such use cases creates more risk than benefit, in my opinion.

> more bugs, specially with partially received frames.

I'm less worried about bugs that cause a failure of functionality than security bugs.

> other mitigations we could do that would not impede the progress we

I've posted about it many times now, with varying levels of detail. I'll try to write something up about the various cross-protocol threat models on the wiki.

> vulnerabilities - which would also be neither fair or productive.

Nothing has been added to the masking proposal since it was originally proposed. It has only been simplified.

> in the spirit of compromise, what aspect of masking as an extension is

Security features should not be optional, they should be mandatory. Using extensions, a mechanism designed for optional features, and then layering requirements on top of that to make masking still be required in the normal case, is needlessly fragile and needlessly complex. I don't agree with adding that fragility without a corresponding benefit.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 10:07:59 -0800

> One large use case is non-browser client systems. I don't see how masking will be useful to them. Masking seems to be protecting against vulnerabilities that affect only browser client systems. Unl…

Note that the proposal under discussion was to make masking a mandatory extension that is always on on both client and server side, and can only be turned off through explicit configuration of the server. I don't see how that helps your use case, unless you have a server that exists only for non-browser clients and can't be accessed at all through browsers. In which case, it's not obvious why you'd want to use WebSocket protocol instead of raw TCP.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Fri, 7 Jan 2011 13:29:57 -0500

On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak <[email-masked]> wrote:
> Security features should not be optional, they should be mandatory. Using extensions,
> a mechanism designed for optional features, and then layering requirements on top of
> that to make masking still be required in the normal case, is needlessly fragile and
> needlessly complex. I don't agree with adding that fragility without a corresponding benefit.

The benefit would hopefully be that we can agree on it, ship it, and
move on to the next thing.

Given the entrenched positions, it isn't clear to me that we can
achieve consensus on masking
not implemented as a mandatory extension.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 7 Jan 2011 19:34:26 +0100

Maciej,

nobody is saying that masking should not be mandatory for situations
where there is the possibility of this class of security
vulnerability.
Nobody is suggesting prioritising data centre convenience over security.

This is not a contest of opposites.

I believe that there must be a way that we can have mandatory masking
for browsers that is suitably robust without sacrificing the
flexibility of the intermediaries, servers and non client browsers.
Are there any actual security flaws in the proposal that I have made?

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 10:47:44 -0800

> not implemented as a mandatory extension.

It doesn't seem like we have consensus on making it a mandatory extension either.

 - Maciej

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 7 Jan 2011 21:35:58 +0100

On 1/7/11 7:47 PM, Maciej Stachowiak wrote:
>> On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak<[email-masked]>  wrote:
a possible benefit from the John proposal is that one has *the freedom* 
to use the type of masking he want,
the one he think is the better or the stronger... if hmac-sha1 is not 
enough strong for him.

/Sal

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 7 Jan 2011 21:44:54 +0100

> Willy, I think we're talking past each other. The threat model I'm talking about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in the browser will effectively let you send any…

Yes, I am. That's why we're discussing about having masking on by default
on the WS client, so that it cannot decide what the bytes will look like
on the wire.

The HTTP API vs WS server was addressed a while ago with the Sec-* headers
that the HTTP API was supposed not to be able to send.

> These are completely separate threat models, and both are important to consider.

Yes, I agree and you're right to remind each one's goal to clarify the discussion.

Thanks,
Willy

---

From: Scott Ferguson <[email-masked]>
Date: Fri, 07 Jan 2011 13:23:07 -0800

> This is actually better than Sec-* headers, because if the server does the check in a buggy way, it won't be able to read from clients at all in the normal case.

To clarify, you're suggesting that the following is a threat:

  frame-header <garbage>
  frame-header <garbage>
  frame-header <garbage>

where

  1. the hijacker cannot predict how the <garbage> bytes will be 
interpreted by the server
  2. the hijacker somehow produces Sec-* headers in the POST request
  3. the server allows a POST to be processed as a websocket request

-- Scott

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 14:25:30 -0800

On Jan 7, 2011, at 1:23 PM, Scott Ferguson wrote:

> 1. the hijacker cannot predict how the <garbage> bytes will be interpreted by the server

Yes. It's a much lesser threat than the case where <garbage> can be controlled, obviously, but sometimes sending parseable commands with a garbage payload is still a risk. I think it would be better not to leave this narrower risk open, if we can avoid it and there's no compelling reason to do otherwise.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 14:27:07 -0800

On Jan 7, 2011, at 12:35 PM, Salvatore Loreto wrote:

> a possible benefit from the John proposal is that one has *the freedom* to use the type of masking he want,
> the one he think is the better or the stronger... if hmac-sha1 is not enough strong for him.
> 

Since we're not going to define any other type of masking at this time, it's not a benefit yet. If we define new masking algorithms in the future, we can allow masking selection without making masking an extension. So even then it's not a real benefit.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Jan 2011 14:29:30 -0800

> that the HTTP API was supposed not to be able to send.

For reasons I've explained a couple of times now, I think masking is a considerably stronger defense against this threat model than Sec-*, so long as entropy from the server is included in the mask. Short version: checking for named headers can easily be subject to bugs where the server is too lenient in its checks (using regexps to parse headers for instance), but masking isn't subject to this risk, because the server *has* to get it right to work correctly in the non-attack case. Since we're adding masking anyway, I'd like it to address this threat too even if we also have a weaker defense for it.

Regards,
Maciej

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Jan 2011 14:42:48 -0800

On Fri, Jan 7, 2011 at 2:29 PM, Maciej Stachowiak <[email-masked]> wrote:

> Willy, I think we're talking past each other. The threat model I'm talking
> about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in
> the browser will effectively let you send any bytes you want as the payload.
> You seem to be talking about the opposite threat model, where WebSocket APIs
> in the browser, to attack HTTP.
>
>
> For reasons I've explained a couple of times now, I think masking is a
> considerably stronger defense against this threat model than Sec-*, so long
> as entropy from the server is included in the mask. Short version: checking
> for named headers can easily be subject to bugs where the server is too
> lenient in its checks (using regexps to parse headers for instance), but
> masking isn't subject to this risk, because the server *has* to get it right
> to work correctly in the non-attack case. Since we're adding masking anyway,
> I'd like it to address this threat too even if we also have a weaker defense
> for it.
>
>
I agree that this is a good plan.

-Ekr

---

From: John Tamplin <[email-masked]>
Date: Fri, 7 Jan 2011 18:22:42 -0500

> I'd like it to address this threat too even if we also have a weaker defense

Plus, AFAIK, there are various ways to send arbitrary headers, such as
with Flash.