I'm going to make a series of statements which I believe to be  
uncontraversial. I'm then going to draw some conclusions from these,  
which seem to be contraversial.

First, the statements:

1) There exist transparent proxies, by which we mean an intermediary  
which the browser and server are both unaware of. (ie, this is  
network transparency and not mere semantic transparency).

2) Some of these transparent proxies can be fooled into rerouting  
requests and caching responses erroneously if the traffic appears to  
be HTTP. This allows an attacker to access data behind a firewall, or  
alternately poison the cache of a proxy.

3) There exists a paper describing an experiment conducted to test  
this hypothesis.

4) The paper also describes a CONNECT request, which causes some  
transparent proxies to cease to treat the remaining data flow as HTTP.

5) The results of this experiment showed that around 1 in every  
10,000 proxies was still trying to find HTTP requests in subseuqent  
data, although no security attacks (point (2)) were found against any  
of the 50,000 or so tested.

6) If masking were deployed, this is believed to prevent any  
transparent proxies from finding HTTP requests in the websocket data  
flow.

7) The attacks in (2) are mountable using Flash and Java.

8) Masking will prevent sendfile()-like interfaces, and in general  
cause dataflow within a device to be routed consistently through the  
CPU, increasing the hardware cost of websockets.

9) AES in particular will have export licensing considerations.

Second, some observations and conclusions:

a) We seem to have decided that we want websockets to be available  
even in environments that have decided to block Java or Flash (or,  
one assumes, other downloadable, non-sandboxed, code). This implies  
we need to be significantly more secure. I don't think this is  
particularly contraversial, but I would offer the suggestion that we  
are unlikely to be able to attain 100% security.

b) We know that a CONNECT request (or pseudo-CONNECT as in my  
proposal) will prevent attacks in some 99.99% of cases, with no cases  
actually found in field testing. This to my mind convinces me that a  
CONNECT is a useful approach. It can be made semantically transparent  
and conformant to existing HTTP specifications quite easily.

c) Whilst I entirely understand that masking prevents some  
theoretical problems, the only experimental data we have suggests  
that such problems are just that - theoretical. This is nothing like  
the kinds of issues we had with open mail relays, where every  
mailserver was, once, affected. This is a handful of transparent  
proxies which might be affected. I think a sense of proportion to our  
response seems sensible. The issues raised in (8) and (9) seem to  
suggest caution.

d) Finally, any proxy affected by the attacks in (2) is also affected  
by Flash or Java (see point 7), so the operators should become aware  
and fix or replace such intermediaries anyway.

My personal conclusion is that the practical benefits of masking  
remain theoretical, and simply do not outweigh the costs, which do  
exist.

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