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

"Roy T. Fielding" <> Thu, 01 September 2011 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EA8821F97F5; Thu, 1 Sep 2011 12:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.266
X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=-3.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tNHmRuv0+5eK; Thu, 1 Sep 2011 12:54:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B5BA821F97EC; Thu, 1 Sep 2011 12:54:10 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 76E3388064; Thu, 1 Sep 2011 12:55:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns;; b=taOz/WQ/r3tniFn7 BBmGkgfmNU00ztgyY5j5g94uO8dkpytbcr0Z0GSPnNLwye6D8RHEZjxabK/svAMG Hm8un8omdU05jqUZtuEwszrjd2j2ZSpqNqRftnIjR7uzdbadcn63C8n/EjFWt8N/ wCLn6Wa+oP8RgyNQM6vFXhToPDA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=Q0J3Ls/RSbCeWloVArZ67ycIJXA=; b=DABjFniJBajECsPbcGrxMZzCgV4p btqaGSae1Wu0QOB8ARAlgGhy4N0jB1qmeWqicqBTnS/W5CqYrWVKqVX5oUsPXs6z slnGW1aJwxxP6vnr9psG4Clh1Pyn6RgPbtVQ/+GUxmj658gRg86AkyZSMtje0bS0 ywmsR4vXqX8FiWE=
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id C187288069; Thu, 1 Sep 2011 12:55:43 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Thu, 01 Sep 2011 12:55:42 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP <>,
Subject: Re: [hybi] 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: Thu, 01 Sep 2011 19:54:11 -0000

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.


Roy T. Fielding                     <>

Begin forwarded message:

> From: "Roy T. Fielding" <>
> Date: March 29, 2011 5:23:33 AM PDT
> To: Server-Initiated HTTP <>
> Cc:
> 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  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                     <>