The way I'm reading this seems to imply that the masking is there in
order to bypass intermediaries, which is absolutely not the case,
quite the opposite instead. The masking was introduced to avoid
getting stuck on supposedly buggy intermediaries that would search
for a valid HTTP request or response past the message boundaries.
However, the net effect of masking is that firewalls that are effective for
HTTP today will not be effective tomorrow.
For a simple analogy: There is significant freak-out today in the security
community about "IPv6 attacks" that amount to sending innocuous traffic in
6-in-4 tunnels (e.g., 6to4). Traffic in a simple 6-in-4 tunnel is completely
visible in principle, but lots of firewalls still have not been upgraded to
read this traffic. So using 6-in-4 tunnels persists as a simple way to bypass
firewalls.
The same is true of WebSockets with masking. Firewalls today can successfully
parse and scan an HTTP stream would still be able to scan WebSocket traffic if
it were not for masking. Masking explicitly defeats these firewalls.
To put it in a more succinct, more alarmist way: How long will it be before
WebSockets become popular for malware distribution?
Masking presents a trade-off between two risks:
-- Without masking, you risk getting trapped in buggy intermediaries, but
continue to benefit from existing protective intermediaries.
-- With masking, you're protected from buggy intermediaries, but you lose any
help from protective intermediaries.
IMO, this is a pretty strong argument against masking, given how low the
observed rate of buggy intermediaries is (~0.0017%) and how high the observed
rate of malware propagation is.
--Richard
The masking uses a low complexity precisely in order to make it
easy for intermediaries to decode the stream at a low cost. Also,
and quite importantly, being able to reuse the existing security
infrastructure is important (user authentication, accounting,
URL filtering, malware site blocking, etc...). The success of BOSH
or XHR precisely comes from the fact that there is no need to
reinvent new security models, new products, to train admins,
etc... What is deployed works.
Naturally, the WebSocket protocol does not have the same network
characteristics as HTTP. The messages exchanged are likely to
be smaller, more interactive, and delivered asynchronously over
a long-lived connection. Unfortunately, those are the same
characteristics of typical denial-of-service attacks over HTTP.
Organizations deploying WebSockets should be aware that existing
network equipment or software monitoring on those ports may need
to be updated or replaced.
The communication pattern is no different than what's done with
existing bidirectional communications over HTTP such as BOSH. It's
even close to XHR in that there may be an avalanche of small packets.
I agree it is important to insist on the traffic pattern, but I don't
think we should be too much alarmist either considering that people
already deploy equivalent mechanisms today.
Last, the protocol design was made with the goal of making it work
over raw TCP later. It's already split in two parts, the handshake
and the data framing. The framing can be reused over any established
connection and masking may be disabled simply by clearing one bit.
I would personally find it more fair to introduce the design by saying
something like this :
The WebSocket protocol is designed to supersede existing bidirectional
communication protocols which use HTTP as a transport layer to benefit
from existing infrastructure (proxies, filtering, authentication). Such
existing protocols were implemented as trade-offs between efficiency and
reliability because HTTP was not initially meant to be used that way.
WebSocket tries to address all of these goals in the same environment,
and as such is designed to work over ports 80 and 443 as well as to
support HTTP proxies and intermediaries, even if this implies some
complexity specific to these environments. The way it is designed
does not limit it to HTTP and future implementations may make use of
simpler handshake over a dedicated port without revinventing everything.
This last point is important to keep in mind because the traffic patterns
of interactive messaging does not much match standard HTTP traffic and
may induce unusual loads on some components.
Regards,
Willy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf