Subject: [hybi] consensus result on Straw Poll: Masking options

From: Salvatore Loreto <[email-masked]>
Date: Thu, 20 Jan 2011 20:27:57 +0100

(as co-chair)

The straw poll on "*Masking options*" is over:
http://www.ietf.org/mail-archive/web/hybi/current/msg05871.html
Thanks to all the people (I have counted around 30) that have answered it
and contributed to the discussion.

The mailing list discussion generated by the straw-poll has showed a 
large consensus
to option #1

where option #1 means simply
"/a random per-frame mask (of fix length) which does not depend on any 
information outside the frame to interpret it/"

The text in the next version (05) of the WebSocket protocol draft will 
reflect this consensus!

best regards
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: John Tamplin <[email-masked]>
Date: Thu, 20 Jan 2011 14:34:54 -0500

On Thu, Jan 20, 2011 at 2:27 PM, Salvatore Loreto <
[email-masked]> wrote:

> The mailing list discussion generated by the straw-poll has showed a large
> consensus
> to option #1
>
> "*a random per-frame mask (of fix length) which does not depend on any
> information outside the frame to interpret it*"
>

While I agree more people agreed to that option, there seemed to be quite a
few with very strongly held opinions against it -- how do we resolve those
objections?

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

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 20 Jan 2011 11:50:41 -0800

If the actual process we're using is just majority vote, then let's not call it "consensus".

 - Maciej

On Jan 20, 2011, at 11:27 AM, Salvatore Loreto wrote:

> (as co-chair)
> 
> The straw poll on "Masking options" is over:
> The mailing list discussion generated by the straw-poll has showed a large consensus
> to option #1 
> 
> "a random per-frame mask (of fix length) which does not depend on any information outside the frame to interpret it"
> 
> 
> The text in the next version (05) of the WebSocket protocol draft will reflect this consensus!
> 
> 
> best regards
> /Sal
> -- 
> Salvatore Loreto
> www.sloreto.com
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 20 Jan 2011 21:09:43 +0100

sorry I should have said "rough consensus"...

/Sal

On 1/20/11 8:50 PM, Maciej Stachowiak wrote:
>> "/a random per-frame mask (of fix length) which does not depend on 
>> any information outside the frame to interpret it/"
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: SM <[email-masked]>
Date: Thu, 20 Jan 2011 12:56:53 -0800

Hello,

The Hybi Working Group co-chair announced that there was rough 
consensus for option #1 based on the discussions generated by the 
straw-poll [2].  Please note that it is not based on the principle of 
majority vote; or that it is a vote as such.

Consensus-building requires significant amounts of discussion.  It is 
a way for objections to be resolved.  When consensus cannot be 
reached, alternative methods such as rough consensus can be used to 
reach a decision.

If anyone believes that the process has not been followed in reaching 
the decision, they can contact the Hybi Working Group Chairs.

Regards,
S. Moonesamy
HyBi WG Secretary

1. http://www.ietf.org/mail-archive/web/hybi/current/msg06028.html

---

From: Adam Barth <[email-masked]>
Date: Thu, 20 Jan 2011 13:46:56 -0800

My read of the poll responses is that several folks had strong
technical objections to #1 and that most respondents said that they
could live with #2 if there were technical reasons why #1 was
insufficient.

Frankly, I'm surprised the chairs chose to declare consensus around #1
as that seems contrary to the messages sent to the list.

Adam

On Thu, Jan 20, 2011 at 12:56 PM, SM <[email-masked]> wrote:
> Hello,
>
> The Hybi Working Group co-chair announced that there was rough consensus for
> option #1 based on the discussions generated by the straw-poll [2].  Please
> note that it is not based on the principle of majority vote; or that it is a
> vote as such.
>
> Consensus-building requires significant amounts of discussion.  It is a way
> for objections to be resolved.  When consensus cannot be reached,
> alternative methods such as rough consensus can be used to reach a decision.
>
> If anyone believes that the process has not been followed in reaching the
> decision, they can contact the Hybi Working Group Chairs.
>
> Regards,
> S. Moonesamy
> HyBi WG Secretary
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 20 Jan 2011 15:04:14 -0800

Hi Adam,
>as that seems contrary to the messages sent to the list.

Sal mentioned that it was rough consensus.

If there are any concerns about the declaration, it would be helpful 
if there is a detailed description of those concerns together with 
the action requested, i.e. any comments that were ignored, etc.

Regards,
S. Moonesamy
HyBi WG Secretary

---

From: Adam Barth <[email-masked]>
Date: Thu, 20 Jan 2011 15:26:35 -0800

> Sal mentioned that it was rough consensus.

Perhaps I'm not versed in the finer distinctions among the different
types of consensus.

> If there are any concerns about the declaration, it would be helpful if
> there is a detailed description of those concerns together with the action
> requested, i.e. any comments that were ignored, etc.

It appears the chair might have overlooked this message:

http://www.ietf.org/mail-archive/web/hybi/current/msg05884.html

On Wed, Jan 12, 2011 at 2:23 PM, Maciej Stachowiak <[email-masked]> wrote:
> On Jan 12, 2011, at 12:00 PM, Salvatore Loreto wrote:
>> 1. a fixed mask carried entirely in the packet.
>
> I can't live with this option. It does not address the HTTP vs. WebSocket threat model.

Specifically, we should not specify a protocol that Maciej cannot live
with.  More generally, ignoring the HTTP vs. WebSocket threat model is
unwise.

Adam

---

From: Dave Cridland <[email-masked]>
Date: Thu, 20 Jan 2011 23:56:55 +0000

> with.  More generally, ignoring the HTTP vs. WebSocket threat model  

I certainly agree with the latter statement, but I felt Maciej's  
issues were amply addressed by preventing that kind of cross-protocol  
attack within the handshake - that is, making it impossible to spoof  
a websocket handshake via Browser sandboxed APIs by usage of Sec-*  
headers, which are a restricted feature.

If this is *not* the case - that is, if one can write arbitrary data  
to sockets - then masking presence or type is rather moot, since one  
can generate AES, if pushed, in JavaScript.

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: S Moonesamy <[email-masked]>
Date: Thu, 20 Jan 2011 16:10:55 -0800

Hi Adam,
>Perhaps I'm not versed in the finer distinctions among the different

I'll go by the following:

    IETF consensus does not require that all participants agree although
    this is, of course, preferred.  In general, the dominant view of the
    working group shall prevail.  (However, it must be noted that
    "dominance" is not to be determined on the basis of volume or
    persistence, but rather a more general sense of agreement.) Consensus
    can be determined by a show of hands, humming, or any other means on
    which the WG agrees (by rough consensus, of course).  Note that 51%
    of the working group does not qualify as "rough consensus" and 99% is
    better than rough.  It is up to the Chair to determine if rough
    consensus has been reached.

>http://www.ietf.org/mail-archive/web/hybi/current/msg05884.html

[snip]

>with.  More generally, ignoring the HTTP vs. WebSocket threat model is

Thanks, I'll forward your comments to the HyBi WG Chairs.

Best regards,
S. Moonesamy
HyBi WG Secretary

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 21 Jan 2011 02:37:31 +0100

>few with very strongly held opinions against it -- how do we resolve those

Well, there were mainly two objections. One, that the protocol does not
look random enough with the simple masking scheme. Assuming that if you
have sufficient control over some service to fake the handshake, it does
not matter whether you can use a Websocket client to send semi-random
data to it, then the only concern there is that the semi-random data may
be picked up by some HTTP-ish intermediary as HTTP traffic, which would
mean, since the best known attack against the simple masking scheme does
work just as well against the simple scheme as it does against the more
complex masking schemes, that the simple masking scheme can be made much
weaker somehow.

So, people can run this by someone who knows their mathematics; if you
can show that very significant impact seems quite plausible, there would
be some in the Working Group to reconsider their position based on this
new information. Alternatively or in addition, gather data on how common
intermediaries are that skip junk and then do something dangerous which
cannot be easily detected. Re-run Adam et al.'s experiment, use a test-
bed browser, talk to antivirus vendors to include checks in their pro-
ducts and share their results, and so on. Showing that there are many of
these intermediaries would also cast significant doubt.

You can also come up with an alternative proposal that makes things more
random but performs much better than what has been proposed. I've looked
at that myself, but if you want something that's easy to implement and
does not increase the message length and performs much better than what
has been proposed, you seem to be kinda out of luck, which isn't so sur-
prising, N bits of randomness take you only so and so far.

The second objection is an alleged lack of protection against absuing a
HTTP client that can be controlled by an attacker just enough to fake a
Websocket handshake but not enough to also properly fake the protocol.
People can prove this exists and make an argument that clients that are
broken in this manner cannot be fixed in sufficient time and numbers to
provide adequate protection, and also provide an argument why we really
should care about Websocket server implementers who cannot be bothered
to validate the handshake as coming from a Websocket client, and offer
an argument that there is an adequate solution that does not draw the
objections against solutions for the first objection here.

It seems from a brief look the people objecting are: James Graham; I've
not been able to find where he detailed his requirements and he did not
say what's wrong with the option favoured by most, so that's nothing I
think could be resolved through discussion; Eric Rescorla suggested the
straw poll because he felt all that could be said had been said, so it
seems there is no opportunity for progress either; Adam Barth seems to
share that sentiment, that's at least what I gathered from him chanting
"ship it", "ship it", "good enough", "good enough" and his eloquent one
liners like "that's a bunch of bunk".

That seems to leave Maciej Stachowiak. He is editor of our requirements
document and the text in that document about cross protocol attacks is
the text he proposed for it. He did not feel like properly proposing a
requirement for his amateur programmer concern, hasn't shown that there
is an actual problem, and hasn't shown that there is a solution that'd
address other people's concerns. Given that no attack is known against
the designs implied by the simple masking scheme that would make it un-
acceptable compared to apparently acceptable proposals, I do think his
requirement, lower-case "should consider and mitigate", is met.

It would seem the the ball is in their court. We've talked about this
for a month, exchanged hundreds of mails over it, but we've not really
learned anything new. We ultimately can't do much when the arguments do
not extend far beyond "I don't like this". Even if you said we have se-
curity concerns on the one hand, and performance concerns on the other,
we wouldn't agree on that. Some seem to think AES is the most secure
scheme because it seems to offer the highest degree of randomness, while
others think that would lead people to falsely assume the protocol
offers confidentiality or message integrity, making it less secure if
randomness does not compensate enough.

Some months back we had people more or less object to "masking" due to
performance considerations; we could not find an alternative, so we did
decided to adopt "masking". Masking schemes that come with orders of
magnitude performance penalties obviously were not easy to sell, and I
suggested people advocating them explain them very carefully. I did not
think resolving this issue through a straw poll that let people select
several out of a few masking schemes was a good idea. Now, people did
not try hard to sell their masking schemes, and people happily did vote
for the options they liked in the poll; at some point we'll have to
allow people to have their objections on record while moving on.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 24 Jan 2011 11:04:54 +1100

> few with very strongly held opinions against it -- how do we resolve those

We make the masking an extension, so that anybody with a strongly held
belief that XOR is insufficient can implement something stronger as an
extension.

For example, if the browser vendors want AES, then they should be able
to implement their clients so that they will insist on an AES masking
extension.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 24 Jan 2011 19:14:58 +1100

> The mailing list discussion generated by the straw-poll has showed a large

Will we apply masking to wss ?

cheers

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Jan 2011 09:30:02 +0100

> Will we apply masking to wss ?
good question!
this has not been discussed at all.

IMO, as individual,
TLS already resolves all the issues that led us to mask frames in ws.

we can choose to be consistent and apply masking to both ws and wss
or apply masking only to ws and leave framing unmasked in wss
both solutions are fine for me

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Dave Cridland <[email-masked]>
Date: Mon, 24 Jan 2011 08:53:15 +0000

> TLS already resolves all the issues that led us to mask frames in  

There are three arguments put forward in support of masking.

Firstly, that it tackles the specific case of intermediaries  
interpreting websocket traffic as HTTP request/response pairs.

Secondly, the more general argument that some other cross-protocol  
attack might be mounted, against (for example) SMTP.

Thirdly, that masking will protect against other security issues we  
have yet to conceive of.

I've never found the second argument remotely convincing, and the  
third smacks of religion, however they both apply equally to 'wss' as  
to 'ws', since:

2) SMTPS and similar do exist, although most non-HTTP protocols have  
switched to an inline TLS negotiation and encrypt opportunistically  
in their respective specifications. (Note I've repeatedly recommended  
this for WebSocket as well).

3) If we are to believe there exist security issues that we haven't  
thought of that masking mitigates, it also seems logical to assume  
that these might also affect end-points, whether or not the  
communication channel is secure.

So while I sincerely hope we won't require masking in the TLS case  
(and, I note, for cleanliness of design, this suggests we should  
consider negotiating masking in order to make ws and wss be as close  
as possible), I shall be somewhat interested to see what arguments  
are put forth against it by proponents of masking.

Dave.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Jan 2011 20:54:43 -0800

On Mon, Jan 24, 2011 at 12:30 AM, Salvatore Loreto
<[email-masked]> wrote:
>>> large

Well, you may believe that, but it's not correct:
The TLS client can generate data which will produce controllable ciphertext
for a number of ciphers.

-Ekr

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Jan 2011 08:20:09 +0000

> The TLS client can generate data which will produce controllable  

That argument would appear to apply equally to HTTPS as to WSS; after  
all, both are simply TLS clients, externally. I'd have to argue that  
this implies a general security issue within TLS, and one that needs  
to be solved there.

Dave.

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 25 Jan 2011 09:35:22 +0100

> The TLS client can generate data which will produce controllable ciphertext
my guess come from the fact that I haven't seen any explicit discussion 
about it.
But I was also pretty sure to be proved wrong, that was the reason why I 
started the thread

/Sal

---

From: Andy Green <[email-masked]>
Date: Tue, 25 Jan 2011 09:27:24 +0000

> But I was also pretty sure to be proved wrong, that was the reason why I

If TLS "produces controllable ciphertext" does that mean every browser's 
SSL is an attack vector for these supposed vulnerable proxies same as 
"ws:// with no munging" was accused of?

I hope the browser vendors will immediately disable SSL support by 
default if so, until munging can be added to ssl: same as they did for 
ws://...

-Andy

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 25 Jan 2011 03:36:52 -0800

On Jan 25, 2011, at 1:27 AM, Andy Green wrote:

> If TLS "produces controllable ciphertext" does that mean every browser's SSL is an attack vector for these supposed vulnerable proxies same as "ws:// with no munging" was accused of?
> 
> I hope the browser vendors will immediately disable SSL support by default if so, until munging can be added to ssl: same as they did for ws://...

The transparent proxy vulnerability stems from sending an HTTP request making use of the Upgrade feature, coupled with the fact that seemingly a number intermediaries don't understand it, and may interpret subsequent content on the same connection as additional requests. You can't do that with TLS, because it starts with a TLS handshake, not an unusual HTTP request. The attacker does not have control over the TLS handshake.

Regards,
Maciej

---

From: Andy Green <[email-masked]>
Date: Tue, 25 Jan 2011 11:51:21 +0000

On 01/25/11 11:36, Somebody in the thread at some point said:

>> If TLS "produces controllable ciphertext" does that mean every
>> browser's SSL is an attack vector for these supposed vulnerable
>> proxies same as "ws:// with no munging" was accused of?

> The transparent proxy vulnerability stems from sending an HTTP
> request making use of the Upgrade feature, coupled with the fact that
> seemingly a number intermediaries don't understand it, and may
> interpret subsequent content on the same connection as additional
> requests. You can't do that with TLS, because it starts with a TLS
> handshake, not an unusual HTTP request. The attacker does not have
> control over the TLS handshake.

Then... in your opinion too there is no reason to have munging on wss://?

-Andy

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 25 Jan 2011 04:08:49 -0800

> Then... in your opinion too there is no reason to have munging on wss://?

I think it could be useful for addressing other threat models than the HTTP intercept proxy. Unfortunately, the chairs chose a masking scheme too weak to defend against attacks using HTTP(S) against a WebSocket server. However, there could still be some protection for infrastructure such as dedicated TLS terminators or man-in-the-middle filtering TLS proxies.

Regards,
Maciej

---

From: Andy Green <[email-masked]>
Date: Tue, 25 Jan 2011 13:24:33 +0000

On 01/25/11 12:08, Somebody in the thread at some point said:

> I think it could be useful for addressing other threat models than
> the HTTP intercept proxy. Unfortunately, the chairs chose a masking
> scheme too weak to defend against attacks using HTTP(S) against a
> WebSocket server. However, there could still be some protection for
> infrastructure such as dedicated TLS terminators or man-in-the-middle
> filtering TLS proxies.

Well the difficulty bothering me is that nobody is going to "get fired" 
for piling more and more obfuscation and computational burden on 
websocket protocol "just in case" without any reproducible scenario as 
you are doing above.   Nobody will "get fired" for including more and 
more vague scenarios into what is meant to be websockets' problem to 
protect against either.  It seems to me to have reached a new pinnacle 
of otherworldliness to demand munging inside an ssl tunnel "just in case".

I don't see how this process leads to designing a good lightweight 
protocol (or makes the world more secure).

-Andy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Jan 2011 06:03:12 -0800

On Tue, Jan 25, 2011 at 12:20 AM, Dave Cridland <[email-masked]> wrote:
> That argument would appear to apply equally to HTTPS as to WSS; after all,
> both are simply TLS clients, externally. I'd have to argue that this implies
> a general security issue within TLS, and one that needs to be solved there.

Why would that be the case?

TLS does not generally attempt to prevent attackers who *know the key* from
generating any bits on the wire of their choice. It's not part of the
communications
security threat model. Why would it be, since the attacker can just send
plaintext communications of their choice down the same channel? The implication
here is simply that HTTPS needs the same treatment as non-HTTP when used
for WS. This is an issue that applies solely to the browser threat
model and needs
to be solved there.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Jan 2011 06:42:44 -0800

On Tue, Jan 25, 2011 at 1:27 AM, Andy Green <[email-masked]> wrote:
> I hope the browser vendors will immediately disable SSL support by default
> if so, until munging can be added to ssl: same as they did for ws://...

I don't know what "ssl:" is.

If you mean "https:", then no.

Look, the same origin policy prohibits you sending arbitrary data
plaintext to arbitrary
locations and then reading back the results. This applies whether you
are doing that
over HTTPS or over HTTP. WebSockets relaxes that constraint on a consensual
basis but in return adds new security features (the consent handshake
+ masking).
I'm simply stating that merely using TLS does not do an adequate job of masking,
i.e., not even as good as the 32-bit moving mask.

This isn't a concern with ordinary HTTPS for the same reason that it's
not a concern
with HTTP: same origin policy. However, that doesn't apply here.

-Ekr

---

From: Andy Green <[email-masked]>
Date: Tue, 25 Jan 2011 14:58:51 +0000

On 01/25/11 14:42, Somebody in the thread at some point said:
> On Tue, Jan 25, 2011 at 1:27 AM, Andy Green<[email-masked]>  wrote:

':' is called a "colon".  It's used in English for punctuation: you can 
read more about it here...

http://en.wikipedia.org/wiki/Colon_(punctuation)

> with HTTP: same origin policy. However, that doesn't apply here.

All the security noise around munging has been so intermediaries between 
the client and the websocket server can't see things under attacker 
control in the TCP packet that an intermediary may allegedly be 
sensitive to.  So it is not requiring sending things to "arbitrary 
locations", just the stated SSL endpoint via these theoretical 
intermediaries.

Since wss:// works by establishing an SSL connection with the 
SSL-capable websocket server endpoint first, if "TLS doesn't do an 
adequate job of masking", then I understand you to mean that the 
websocket traffic inside can be formed such that the TCP packet content 
can be under attacker control after encryption: to have the same magic 
text that causes intermediaries to be attacked in the websocket traffic 
case.

I take you to mean that because otherwise, I don't see why what your 
saying about the munging power of SSL encryption is relevant to the 
question of needing munging inside an ssl tunnel for websocket traffic.

-Andy

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Jan 2011 15:01:24 +0000

On Tue Jan 25 14:03:12 2011, Eric Rescorla wrote:
> generating any bits on the wire of their choice.

If you're saying that the browser generates the key, thus rendering  
it out of control of the attacker, then this seems a fine argument  
that HTTPS is immune from such problems. But I don't understand why  
the protocol ostensibly carried beneath the TLS layer could have any  
bearing on whether, if the attacker can choose the key, being able to  
choose the bits on the wire becomes a threat or not. Therefore WSS  
must also be immune, surely?

Dave.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 25 Jan 2011 10:02:43 -0500

> >>> Will we apply masking to wss ?

just as with https, wss may be TLS terminated in the data center at
something less than end to end.. given that one of the masking use cases
was reverse proxies that you would find in the datacenter we still want
that masking even if the TLS had proven sufficient.

---

From: Andy Green <[email-masked]>
Date: Tue, 25 Jan 2011 15:07:56 +0000

> that masking even if the TLS had proven sufficient.

If you believe that the munging does anything useful, that is indeed a 
good consistent reason for having it on inside wss://.

-Andy

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 25 Jan 2011 16:12:43 +0100

> that masking even if the TLS had proven sufficient.

thanks to both Eric and Patrick for their explanations/use cases.
I was not against, just asking so to clarify a point it was not; at 
least for me.

/Sal

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Jan 2011 07:47:17 -0800

On Tue, Jan 25, 2011 at 6:58 AM, Andy Green <[email-masked]> wrote:
> Since wss:// works by establishing an SSL connection with the SSL-capable
> websocket server endpoint first, if "TLS doesn't do an adequate job of
> masking", then I understand you to mean that the websocket traffic inside
> can be formed such that the TCP packet content can be under attacker control
> after encryption:

Yes, that is correct. More properly, if the client knows the
cryptographic keys used for
TLS (which of course can be passed back by the server) then he can generate any
payload (modulo the TLS framing) of his choice. I thought this was a well-known
property, as it follows immediately from the fact that TLS can be configured to
use RC4.

> to have the same magic text that causes intermediaries to
> be attacked in the websocket traffic case.

That's a slightly different question.

You're right that SOP isn't relevant here--I plead lack of caffeine
for my confused response.

In general, w/o WS you're limited to whatever you can cram into
XmlHttpRequest() whereas
with WS you can send anything you want. So, WS isweaker in this
respect and masking
inside the TLS channel would make it more secure. I think its an open
question whether it's
necessary, but what's the argument *against* masking inside the channel?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Jan 2011 07:52:29 -0800

On Tue, Jan 25, 2011 at 7:01 AM, Dave Cridland <[email-masked]> wrote:
>> > all,
> If you're saying that the browser generates the key, thus rendering it out
> of control of the attacker, then this seems a fine argument that HTTPS is
> immune from such problems. But I don't understand why the protocol
> ostensibly carried beneath the TLS layer could have any bearing on whether,
> if the attacker can choose the key, being able to choose the bits on the
> wire becomes a threat or not.
I'm sorry, I don't understand what you're saying here.

TLS can be configured to use stream ciphers. With a stream cipher, if
you can predict
the key and can control the plaintext you can generate ciphertext
(i.e., what appears on
the wire) of your choice. In the standard TLS configuration, the
client (i.e., the browser)
and the server (in this case the attacker) both know the key. The
attacker can feed
it back to the JavaScript in the browser, thus allowing him to
generate any plaintext
(and hence ciphertext) of his choice in the client->server direction.

>Therefore WSS must also be immune, surely?

I don't see how that follows. At best it follows that HTTPS is equally
vulnerable. However,
as I argued to Andy, since WS affords better control of the stream,
then I don't think this
is actually true.

-Ekr

---

From: Andy Green <[email-masked]>
Date: Tue, 25 Jan 2011 16:31:32 +0000

On 01/25/11 15:47, Somebody in the thread at some point said:
> On Tue, Jan 25, 2011 at 6:58 AM, Andy Green<[email-masked]>  wrote:

Right... I wasn't trying to argue against it, just establishing that we 
are both in the end talking about the same process (and we are).

> for my confused response.

No problem, it seems Salvatore appreciated it anyway 8-P

> necessary, but what's the argument *against* masking inside the channel?

The extra SHA-1s per packet at the server (who has to do them too to 
unmunge the packet) will add up, if they could be avoided they should be.

Anyway while munging is accepted into the standard as being websocket 
business as it is, seems to me there is no point trying to ameliorate 
the ssl munging situation given Patrick's point about not letting it 
wander about unmunged behind the SSL endpoint, so nothing to argue.

-Andy