Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 1 Sep 2011 12:55:42 -0700

I sent this originally in March, before the last call, but I see
that it still applies for draft-ietf-hybi-thewebsocketprotocol-13.

If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please
add an IESG note to the effect of:
=========
   The WebSocket protocol is designed with an assumption that
   TCP port 80 or 443 will be used for the sake of tunneling raw
   socket exchanges over HTTP.  The result is a convoluted and
   inefficient exchange of hashed data for the sake of bypassing
   intermediaries that may be routing, authenticating, filtering,
   or verifying traffic on those ports.  The sole reason for using
   ports 80 and 443, and hence requiring the hashed data exchange,
   is because many organizations use TCP port blocking at firewalls
   to prevent unexpected network traffic, but allow the HTTP ports
   to remain open because they are expected to be used for normal
   Web request traffic.  WebSocket deliberately bypasses network
   management constraints in order to enable Web application
   developers to send arbitrary data though a trusted port.

   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.
=========

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>

Begin forwarded message:

> From: "Roy T. Fielding" <[email-masked]>
> Date: March 29, 2011 5:23:33 AM PDT
> To: Server-Initiated HTTP <[email-masked]>
> Cc: [email-masked]
> Subject: reuse of port 80/443 in hybi
> 
> I am finding it difficult to participate in hybi in any meaningful
> way due to the very poor assumption that websockets traffic should
> use the same ports as Web traffic.  Apparently, this "decision" was
> made on the basis of hums at an in-person WG meeting and the chairs
> believe it to be consensus (and thus quash any discussion that has
> apparent consensus due to the extent to which people keep bringing
> up old issues).  It might even make some sense, given the name of
> this working group.
> 
> Unfortunately, it is a fatal error.  The rest of the protocol
> discussion is predicated on it, and enormously complex, for the
> sole reason of that initial error in design.  More the pity.
> It assumes that the network infrastructure that currently
> monitors and balances traffic over 80/443 is going to instantly
> adapt to TCP-over-HTTP, as opposed to treating it like a denial
> of service attack.
> 
> Browsers are fully capable of opening up new ports in firewalls
> simply by concerted use of open standards.  Many other applications
> do so without this painful corruption of existing protocols. Yes,
> it takes time (but not as much time as one would think).  Yes,
> there will be some companies that forcibly block some ports,
> just like there are some companies that forcibly block HTTP
> sites like facebook.com.  That is their right.  If the protocol
> is safe to use, it will be deployable over time.  If not, then
> it shouldn't make the Web situation worse by increasing the
> amount of packet filtering at firewalls.
> 
> So, I don't think the hybi work is worth continuing.  The rest of
> the protocol decisions simply don't matter -- any of the already
> deployed proprietary hacks are better by default because they
> are no worse than hybi and don't have the imprimatur of the IETF.
> I'd rather develop a protocol that works with network administration
> rather than against it.
> 
> I only ask that an IESG note be added to the final specification
> to the effect that this protocol knowingly misuses the Internet
> for the sake of bypassing organizational security.  Be honest and
> let the admins make their own decisions.
> 
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>

---

From: Hector <[email-masked]>
Date: Fri, 02 Sep 2011 05:53:07 -0400

Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do 
handshaking and authentication to even allow it in the first so?  If 
so, whose network management constraint is it bypassing?

Roy T. Fielding wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Sep 2011 12:09:50 +0200

2011/9/2 Hector <[email-masked]>:
> handshaking and authentication to even allow it in the first so?  If so,
> whose network management constraint is it bypassing?

I suppose Roy talks about company firewalls or HTTP proxies inspecting
HTTP traffic nature.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Sep 2011 12:54:42 +0200

Hi,

I believe that almost everything Roy says below is non-controversial; if 
we can tune the language to be less offensive it might fit well into the 
Introduction (and not require an IESG Note to get into the document).

Best regards, Julian

On 2011-09-01 21:55, Roy T. Fielding wrote:
> Roy T. Fielding<http://roy.gbiv.com/>
>
> Begin forwarded message:
>
>> From: "Roy T. Fielding"<[email-masked]>
>> To: Server-Initiated HTTP<[email-masked]>
>> Cc: [email-masked]
>> Roy T. Fielding<http://roy.gbiv.com/>
>
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Sep 2011 15:17:45 +0200

On 2011-09-03 12:54, Julian Reschke wrote:
> ...

Like that...:

s/convoluted and inefficient/complex/

s/sole//

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 3 Sep 2011 10:03:17 -0700

I don't know if this is a cultural issue or not, but neither of those
changes is an improvement, nor should they be any less offensive.
Convoluted and inefficient describes the hashing algorithm in the
least offensive way possible -- "complex" doesn't say anything.
There are a lot of complex algorithms (e.g., TLS) that are
necessarily so.

And I gave the sole reason the WG has for using those ports -- I don't
want people to imagine there might be any other (sane, unselfish, etc.)
reasons.

Besides, what I wrote is entirely factual -- the offensive version
would have melted your LCD.

....Roy

---

From: Joel Martin <[email-masked]>
Date: Sat, 3 Sep 2011 13:51:44 -0500

Roy,

You may feel that the wording of your note is not pejorative (because what
you wanted to say is so much more so), but the tone and wording come across
that way even if it is technically accurate.

Having a note in the spec that WebSocket connections over port 80 and 443
wlll have traffic patterns that are substantially different than normal HTTP
patterns and how this might impact existing infrastructure is probably
worthwhile but I don't think most of your note is helpful or serves much
purpose (except as a passive aggressive way to express an opinion that the
current WebSocket protocol is fatally flawed).

Just one example: "convoluted and inefficient". A simple 4-byte running XOR
hash is convoluted? Certainly it's slightly more complicated than raw bytes
or plain text. But convoluted seems like a stretch by any measure.
Inefficient? Again, it's obviously more inefficient than just passing bytes,
but if you are going to do an operation to a series of bytes, it doesn't get
much more efficient than XOR. And there was a fair bit of testing of the
efficiency of different hashing algorithms on different platforms and this
current algorithm was deemed not overly inefficient (if you disagree, please
provide data).

So I think your real objection is that the current WebSocket protocol is
more complicated and more inefficient than if WebSockets used a new set of
well defined ports (without the ability to pick other ports, or with 80 and
443 explicitly disallowed or the same problem crops up again) and was able
to safely send data without hashing. In which case I think your real
disagreement is not with the outcome of the working group but with
requirement #7 (#6 in the original) of the WebSocket requirements document:
http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements-02.

Personally, I think the ability to use port 80 and 443 for WebSockets is
valuable and worthwhile and I agree with the requirement. But those ports
are not mandatory (just defaults) and if it turns out that this is a mistake
then it really isn't that difficult for web servers to deny WebSocket
handshakes on port 80,443 and force WebSocket services to use other ports.
It would also be simple to update the spec in the future and make
client-to-server masking optional for ports that are not 80/443.

Regards,

Joel Martin

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 3 Sep 2011 21:43:23 +0200

Hi Julian, Roy,

>    developers to send arbitrary data though a trusted port.

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.

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.

>    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

---

From: Joel Martin <[email-masked]>
Date: Sat, 3 Sep 2011 18:07:24 -0500

>   may induce unusual loads on some components.

+1. I like that phrasing. It summarizes the requirements document pretty
well and also indicates to admins that they may see a change in observed
traffic patterns (in a neutral way).

Joel Martin

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sun, 4 Sep 2011 04:07:32 +0200

> well

Yet it never was worded that way when this WG started debating mainly WS. In
fact, I don't recall any other protocol being discussed on this board so I
disagree with the term "requirement" in this very case.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

---

From: Joel Martin <[email-masked]>
Date: Sun, 4 Sep 2011 15:52:30 -0500

On Sat, Sep 3, 2011 at 9:07 PM, Sylvain Hellegouarch <[email-masked]> wrote:

> Yet it never was worded that way when this WG started debating mainly WS.
> In fact, I don't recall any other protocol being discussed on this board so
> I disagree with the term "requirement" in this very case.
>
>
My point is that Willy's paragraph is a concise summary the current (and
original) requirements document for WebSockets and the HyBi charter too for
that matter:

Original WebSocket requirements doc:
http://tools.ietf.org/html/draft-loreto-hybi-requirements-00
Current WebSocket requirements doc:
http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements<http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements-02>

Original WebSocket charter:
http://tools.ietf.org/wg/hybi/charters?item=charter-hybi-2010-01-26.txt
Current WebSocket charter: http://www.ietf.org/dyn/wg/charter/hybi-charter

IMO, the current protocol design fits quite well with the HyBi charter and
WebSocket requirements. One could argue that the charter and requirements
document are flawed, but given the starting point, the current result has
almost fulfilled the original vision (the remaining item is wide adoption,
but that seems very likely assuming the WG work isn't derailed in the
meantime).

Regards,

Joel Martin

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 5 Sep 2011 11:33:24 +0200

> but that seems very likely assuming the WG work isn't derailed in the

Fair enough. Though I'd say we still lack large set of implementations,
specially at intermediaries side, as well as other use-cases beyond what was
initially provided.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Sep 2011 17:18:11 +0200

On 2011-09-03 20:51, Joel Martin wrote:
> Roy,
>
> You may feel that the wording of your note is not pejorative (because
> what you wanted to say is so much more so), but the tone and wording
> come across that way even if it is technically accurate.
>
> Having a note in the spec that WebSocket connections over port 80 and
> 443 wlll have traffic patterns that are substantially different than
> normal HTTP patterns and how this might impact existing infrastructure
> is probably worthwhile but I don't think most of your note is helpful or
> serves much purpose (except as a passive aggressive way to express an
> opinion that the current WebSocket protocol is fatally flawed).
>
> Just one example: "convoluted and inefficient". A simple 4-byte running
> XOR hash is convoluted? Certainly it's slightly more complicated than
 > ...

Wild guess: back when that text was written, the exchange was more 
complex than it is now, right?

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 11:54:04 -0600

> Introduction (and not require an IESG Note to get into the document).

Indeed, it would be best if the WG could come to consensus on text,
rather than having the IESG impose something. Willy Tareau proposed text
that might fit the bill:

###

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.

###

IMHO it would be good to include a reference to RFC 6202 in the first
sentence.

Peter, as responsible AD

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 6 Sep 2011 13:57:59 -0400

> 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

---

From: Greg Longtin <[email-masked]>
Date: Tue, 6 Sep 2011 13:10:50 -0500

Richard,

> To put it in a more succinct, more alarmist way: How long will it be
> before WebSockets become popular for malware distribution?

For traffic *from* client to server?  Seems odd.

As to traffic from server to client, that isn't masked, and hence, a
firewall could parse and scan it...

Greg Longtin

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Sep 2011 20:34:03 +0200

> firewall could parse and scan it...

I would also add that the part that is concerned is *not* within the
HTTP messaging and that firewalls that would currently scan this would
have to carefully consider the Upgrade header's value as well otherwise
they could not emit any hypothesis about what they see there. For instance,
the string "../../bin/sh -c" could be perfectly valid in an RDP session
that runs over HTTP in Upgrade mode but might be dangerous in case of
normal HTTP or even WebSocket. The difference is only known by the
contents of the Upgrade header, otherwise it's random junk.

So the masking here does not remove any ability for firewalls or other
intermediaries to analyze a stream they were already able to analyze.
And the masking was made cheap precisely so that those components will
be adapted to scan the contents at a low cost.

Regards,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 6 Sep 2011 12:56:32 -0700

On Sep 3, 2011, at 11:51 AM, Joel Martin wrote:

> You may feel that the wording of your note is not pejorative (because what you wanted to say is so much more so), but the tone and wording come across that way even if it is technically accurate.

Of course it is pejorative.  How can I explain this any better?
The technique being used by WebSockets to bypass organizational
security will cause deliberate harm to those networks which are
actively monitoring standard ports for attacks of various sorts.
It will also cause harm to existing HTTP services because the
additional content scanning will cause all network services on
those ports to be slowed.

Causing harm is bad.  I don't have non-pejorative words for it.

The sole reason for this harm is because the individuals who
organized this working group believe it is "too difficult" to
introduce new Internet protocols on their own ports.  The IESG
may or may not wish to respect those people's desires, since
they clearly are not managers of corporate networks, but I think
they would at least like to warn network managers that such a
thing is coming their way.  That is why we have IESG notes.

> Having a note in the spec that WebSocket connections over port 80 and 443 wlll have traffic patterns that are substantially different than normal HTTP patterns and how this might impact existing infrastructure is probably worthwhile but I don't think most of your note is helpful or serves much purpose (except as a passive aggressive way to express an opinion that the current WebSocket protocol is fatally flawed).
> 
> Just one example: "convoluted and inefficient". A simple 4-byte running XOR hash is convoluted? Certainly it's slightly more complicated than raw bytes or plain text. But convoluted seems like a stretch by any measure. Inefficient? Again, it's obviously more inefficient than just passing bytes, but if you are going to do an operation to a series of bytes, it doesn't get much more efficient than XOR. And there was a fair bit of testing of the efficiency of different hashing algorithms on different platforms and this current algorithm was deemed not overly inefficient (if you disagree, please provide data).

I am a server developer.  Yes, it is obviously more inefficient
to change every byte, just as it is obviously convoluted to exchange
a true random hash key as part of the connection set-up.  Using TLS
all the time would have been just as complex but far less convoluted
(TLS is well-tested, deployed, and frequently implemented in hardware).
And let's not forget that the initial setup exchange itself (Upgrade)
is also required for the sole purpose of doing this over ports 80/443.
All of it, BTW, just to invoke a generic framing session that handles
some of TCP over TCP (without adding anything interesting by default,
like a MUX layer).

> So I think your real objection is that the current WebSocket protocol is more complicated and more inefficient than if WebSockets used a new set of well defined ports (without the ability to pick other ports, or with 80 and 443 explicitly disallowed or the same problem crops up again) and was able to safely send data without hashing. In which case I think your real disagreement is not with the outcome of the working group but with requirement #7 (#6 in the original) of the WebSocket requirements document: http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements-02. 

My disagreement is with the content of a proposed standard.

I don't care what the WG thinks its requirements are, nor
how it has made decisions on the basis of those requirements.
As I said before, I found it useless to participate within
the WG under those conditions because they were deliberately
designed to fail.  So, I stopped participating.  That does not
mean the WG deliverables are not subject to last call review.

> Personally, I think the ability to use port 80 and 443 for WebSockets is valuable and worthwhile and I agree with the requirement. But those ports are not mandatory (just defaults) and if it turns out that this is a mistake then it really isn't that difficult for web servers to deny WebSocket handshakes on port 80,443 and force WebSocket services to use other ports. It would also be simple to update the spec in the future and make client-to-server masking optional for ports that are not 80/443.

I think the note should reflect what has been specified, not what
might be specified at some point in the future.

Yes, if the protocol had been specified as "try this new port first
and only fall back to 80/443 as a last resort" then I would have more
sympathy to the way it has been designed.  There are many examples
of doing that in practice, though none of them are called standards.
However, that is not what is specified, that is not what browsers are
implementing, and that is not what network managers will soon see
on their monitors.

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Sep 2011 22:22:19 +0200

> actively monitoring standard ports for attacks of various sorts.

Roy please, it's not "to bypass", it's the opposite. Using in place
proxies, URL classification, anti-virus, malware blocking, authentication
etc... is a way to *respect* organizational security. The reason why
alternative solutions do work in corporate environments precisely is
because they are compatible with deployed and well-controlled
technology. Corporate admins are much less tempted by deploying new
protocols they don't understand with new components and their bag
of authentication mechanisms etc...

Opening any port different from 80 in corporate environment generally
is a no-go. 443 is generally filtered by white lists and only accessible
to a small number of users because it's not analysable. Some products do
emit fake certificates to spoof the original site to be able to open the
stream and analyze the contents. This causes issues such as end-users not
being able to decide whether or not they accept an unknown cert.

I'm not fond either of passing everything on top of port 80. But it's
what offers the finest control everywhere. HTTP offers the user
authentication and server qualification that TCP lacks. And there are
much less risks of seeing a port being abused. Hey BTW I'm right now
responding from a location I can only escape by abusing a non-80 port...
If this place only had to deal with port 80 and normal proxies, I could
not have accessed my mail over SSH. That's why corporate admins prefer
to focus on what they can control (eg: HTTP) and not on every shiny new 
protocol.

> those ports to be slowed.

There is no reason to slow those components down if there is no
traffic increase. The cost of analysing a 1MB WS message or a 1MB
HTTP response basically is the same.

> introduce new Internet protocols on their own ports.

I don't agree with you on this point. It's not a matter of difficulty
but a matter of adoption. If you offer something that nobody deploys
because admins are reluctant, you'll still see BOSH and friends everywhere
because it will be what already works.

> The IESG

The warning is important and I agree with you on this point.

> (TLS is well-tested, deployed, and frequently implemented in hardware).

But TLS still costs more and is closed at many places (such as where I'm
right now). TLS+NPN will offer admins a greater control over what's
transiting (so that they don't have to let users SSH over their proxies)
but still it will prevent content filters from *seeing* what's exchanged.

> designed to fail.  So, I stopped participating.

I must say it bugs me to understand how you can disagree with the
outcome of a design when you already disagree with the established
requirements. Maybe you should have fought more at the beginning
to explain why you thought those requirements were stupid and try
to ensure the WG would not start its work at all then.

> of doing that in practice, though none of them are called standards.

One point that was raised was the time to fail. It's very hard to
distinguish between a slow success and a slow failure. Also it does
not address the requirements in corporate networks concerning user
authentication, accounting, site filtering, content filtering, etc...
and in the end port 80 would still be the de-facto standard.

Regards,
Willy

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 6 Sep 2011 21:04:24 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard L. Barnes
> Sent: 06 September, 2011 10:58
> To: Willy Tarreau
> Cc: Roy T. Fielding; Server-Initiated HTTP; [email-masked]; [email-masked]
> Subject: Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-
> thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
> 
> > getting stuck on supposedly buggy intermediaries that would search for
> > a valid HTTP request or response past the message boundaries.
> 
> 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?
> 
> -- Without masking, you risk getting trapped in buggy intermediaries, but
> continue to benefit from existing 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.
> >
> > 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Sep 2011 22:05:48 +0100

Hi Richard,

> 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.

I'm not sure what you're comparing there. Can you elaborate?

In fact, I'm not sure I get the malware argument. Malware
authors are also free to obfuscate or mask their stuff,
when both sides of the conversation but not the intermediaries
are controlled as would be the case here. Or maybe I'm
missing something?

I personally think the masking thing is pretty ugly. But I
have to (reluctantly) admit I think it does what its
supposed to do. At this stage I think it comes down to
either doing the masking or not using port 80.

Ta,
S.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Sep 2011 23:24:25 +0200

On Tue, Sep 06, 2011 at 10:05:48PM +0100, Stephen Farrell wrote:
> >observed rate of buggy intermediaries is (~0.0017%) and how high the 
> >observed rate of malware propagation is.
> 
> 

No you're not missing anything, some malware even communicate
via micro-messaging such as twitter nowadays, this is plain
valid HTTP !

> either doing the masking or not using port 80.

Indeed. Also the masking is optional in the protocol but defined
as mandatory in clients. So some special applications might very
well not implement it at all and some day it's very likely that
we'll get rid of it by default, just like the web doesn't work
well if you omit to post a Host header today.

Regards,
Willy

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 6 Sep 2011 17:36:01 -0400

> I'm not sure what you're comparing there. Can you elaborate?

Sorry, should have provided references.  The observed rate of cache poisoning vulnerability is from the "Talking to Yourself for Fun and Profit" paper.  They did an empirical study (using an ad buy) of several variants of the WebSocket protocol.  They found 8 users vulnerable out of around 54,526 tested. So I actually had my math a bit wrong, the prevalence is more like 0.015%.
<http://w2spconf.com/2011/papers/websocket.pdf>

It's worth noting, though, that their experiment used an older version of the protocol (-03 at the latest), and is not compliant with whichever version they used.  In particular, they omit the data framing header.  Since these octets seem unlikely to increase the probability of a proxy accepting a poisoning request, I would regard their number as an upper bound on the prevalence of buggy proxies.

Another interesting finding in that paper was that there were no observed instances of a CONNECT-based variant of the protocol successfully poisoning proxies (on the same sample set of ~54k users).  This might lead one to think that the problem that masking solves could also be avoided by using HTTP differently.  I think that this option was discussed in the WG and decided against, but I don't know why. 

> are controlled as would be the case here. Or maybe I'm

It's a question of how many layers of obfuscation the firewall has to manage.  Malware scanners have to deal with polymorphism already today, and there are lots of approaches, so that's not really an is.  Masking is a layer on top that the firewall would have to unwrap.  Just as with 6to4, in principle, masking is just an annoyance, another thing to decapsulate.  In practice, firewalls have not kept up with these things, so requiring masking on WebSockets is likely to create a reasonably long-lived channel for circumventing firewalls.

> either doing the masking or not using port 80.

I'm sort of of the same feeling.  I don't disagree that masking solves the problem it sets out to.  The question is whether there are other ways to solve the problem that are simpler, with fewer side effects.

--Richard

---

From: John Tamplin <[email-masked]>
Date: Tue, 6 Sep 2011 17:44:08 -0400

On Tue, Sep 6, 2011 at 5:36 PM, Richard L. Barnes <[email-masked]> wrote:

> I'm sort of of the same feeling.  I don't disagree that masking solves the
> problem it sets out to.  The question is whether there are other ways to
> solve the problem that are simpler, with fewer side effects.
>

Please, let's not reopen months of discussion about exactly that topic.
 Many alternatives were proposed, and XOR masking was the only thing that we
could get consensus on as reasonably acceptable to everyone.

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

---

From: SM <[email-masked]>
Date: Tue, 06 Sep 2011 14:48:44 -0700

Hi Richard,
At 14:36 06-09-2011, Richard L. Barnes wrote:
>Another interesting finding in that paper was that there were no 
>observed instances of a CONNECT-based variant of the protocol 
>successfully poisoning proxies (on the same sample set of ~54k 
>users).  This might lead one to think that the problem that masking 
>solves could also be avoided by using HTTP differently.  I think 
>that this option was discussed in the WG and decided against, but I 
>don't know why.

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

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Sep 2011 22:47:19 +0100

> <http://w2spconf.com/2011/papers/websocket.pdf>

Right. One of my discuss points on this was that they
need to reference.

> It's a question of how many layers of obfuscation the firewall has to manage.  Malware scanners have to deal with polymorphism already today, and there are lots of approaches, so that's not really…

Ok. Thanks.

> I'm sort of of the same feeling.  I don't disagree that masking solves the problem it sets out to.  The question is whether there are other ways to solve the problem that are simpler, with fewer si…

Fair enough. I think what you're saying is we can go with
masking, or revisit what the WG decided (masking) in
reaction to the above-cited paper, or else get them off
port 80.

Pragmatism is certainly pushing us towards the first of
those;-)

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Sep 2011 10:35:00 -0600

>    may induce unusual loads on some components.

Willy, I appreciate the proposed text. Here is a slightly tweaked version.

###

   The WebSocket protocol is designed to supersede existing
   bidirectional communication technologies which use HTTP as a
   transport layer to benefit from existing infrastructure
   (proxies, filtering, authentication).  Such technologies
   were implemented as trade-offs between efficiency and reliability
   because HTTP was not initially meant to be used for bidirectional
   communication (see [RFC6202] for further discussion).  The
   WebSocket protocol attempts to address the goals of existing
   bidirectional HTTP technologies in the context of the existing
   HTTP infrastructure; as such, it is designed to work over HTTP
   ports 80 and 443 as well as to support HTTP proxies and
   intermediaries, even if this implies some complexity specific to
   the current environment.  However, the design does not limit
   WebSocket to HTTP, and future implementations could use a
   simpler handshake over a dedicated port without revinventing
   the entire protocol.  This last point is important because the
   traffic patterns of interactive messaging do not closely match
   standard HTTP traffic and can induce unusual loads on some
   components.

###

I shall enter an RFC Editor Note in the datatracker with that text as a
placeholder, with the understanding that the text might change based on
further discussion.

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 8 Sep 2011 20:14:57 +0200

Hi Peter,

> placeholder, with the understanding that the text might change based on

Looks fine to me.

Thanks,
Willy