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

Willy Tarreau <> Tue, 06 September 2011 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E17021F8E72; Tue, 6 Sep 2011 13:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.734
X-Spam-Status: No, score=-3.734 tagged_above=-999 required=5 tests=[AWL=-2.291, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pE74CpikjYIQ; Tue, 6 Sep 2011 13:20:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D279921F8E76; Tue, 6 Sep 2011 13:20:40 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p86KMJpu016513; Tue, 6 Sep 2011 22:22:19 +0200
Date: Tue, 6 Sep 2011 22:22:19 +0200
From: Willy Tarreau <>
To: "Roy T. Fielding" <>
Message-ID: <>
References: <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Cc:, Server-Initiated HTTP <>,
Subject: Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2011 20:20:44 -0000

On Tue, Sep 06, 2011 at 12:56:32PM -0700, Roy T. Fielding wrote:
> 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.

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 

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

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.

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

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

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

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

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.

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

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.

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

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.