RE: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprot

Today, firewalls are not effective against HTTP. Websockets do not represent a 
new communication pattern leveraging HTTP. There is a VERY old tradition of 
doing this, some with wide distribution (see RFC6202 for some discussion of 
things websockets will hopefully replace). 

So the problem is not new, and HTTP is already being used for communication 
patterns different from the original request/response. Some firewalls may 
already be cognizant of some of those approaches, but given the ad hoc nature, 
I don't believe they handle all the possibilities. Of course, if traffic is 
over HTTPS the firewalls can't do much against that (ignoring some dirty 
tricks).

What is new is that websockets provides a clear indication that a communication 
pattern different from the basic request/response is about to take over: the 
websocket handshake. This handshake is actually a good tool that was previously 
unavailable to network administrators. They can use it to impose a given policy 
within their site, if that's what is desired. There is no way to practically do 
this with other approaches at asynchronous communications over HTTP.

If the firewalls decide to allow websocket traffic through, the masking was 
designed to allow them to trivially inspect the subsequent  data traffic, given 
that the masking key is sent along with each frame.

> -----Original Message-----
> From: hybi-bounces(_at_)ietf(_dot_)org 
> [mailto:hybi-bounces(_at_)ietf(_dot_)org] On Behalf Of
> Richard L. Barnes
> Sent: 06 September, 2011 10:58
> To: Willy Tarreau
> Cc: Roy T. Fielding; Server-Initiated HTTP; ietf(_at_)ietf(_dot_)org; 
> iesg(_at_)iesg(_dot_)org
> Subject: Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-
> thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
>
> > 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
> _______________________________________________
> hybi mailing list
> hybi(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf