Re: [hybi] Moving to a CONNECT-based handshake

"Roy T. Fielding" <> Wed, 01 December 2010 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1259C28C127 for <>; Wed, 1 Dec 2010 12:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UY4J8KSqzrQu for <>; Wed, 1 Dec 2010 12:20:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B6D3E28C0EF for <>; Wed, 1 Dec 2010 12:20:33 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id E3C8635C074; Wed, 1 Dec 2010 12:21:47 -0800 (PST)
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=2Eou7IBOhmNEBdx6 vueOcLL2YwzTyHHph66onlOuj2QFCxdJB3YitZaC81KfMsE/8OLrtASuJc5AKLK2 gBANw7+uQLcH34uxYETvdlNCaeAf2kUMqtBnNlVAPIOCw4VZH4i39h829emahOgK 0liZAmy7oZSMCwp8nx7ICMtwOlE=
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=vt5VWmykVdIJqREm9jV33TY/c4s=; b=ZGljVHTzt72ivjyHjzk77n9JXVYL oIOVAYZ9p2zJ4dhMLfeG8hIACZr9CQ8cyXOo2FJiiZNKLtprbSrulzEXQ8tKpz7Z sySMg0vymgOv4PDGFE8vF/DlmdbTpxfB/2OcuLnvemPdBRIBDadUUoA6fBvzb03m kbI5Y+q/s0rzSi8=
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPA id 7680535C070; Wed, 1 Dec 2010 12:21:47 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="utf-8"
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Wed, 01 Dec 2010 12:21:46 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <op.vmzqkhszidj3kv@simon-pieterss-macbook.local> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.1082)
Cc: "" <>
Subject: Re: [hybi] Moving to a CONNECT-based handshake
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Dec 2010 20:20:36 -0000

On Dec 1, 2010, at 8:45 AM, Ian Fette (イアンフェッティ) wrote:

> We all know that WS over port 80 faces obstacles. That's been known for a long time, nothing has changed, and yet there remains a group that wishes to try to use it. As long as the problems are known, I see no reason to try to forbid it. 
> As for strong objectors, it seems like many people who are implementing have voiced strong support for adams proposal, modulo some tweaks here and there. I would like to see how far we can get.

We will get nowhere.  Adam's proposal is to use CONNECT, a method specifically
designed for telling a normal (non-intercept, non-reverse) proxy to create a
TCP tunnel to some other host:port, and he suggest using it to do something
contrary to its method definition and the HTTP architecture in general.
That would violate both CONNECT semantics and the HTTP syntax for non-proxy
requests (not to mention our hybi charter).  Please understand that such an
abomination will not be allowed in an Internet proposed standard even if the
browsers deployed it, and thus should be rejected out of hand.

Listen to the input you have received already.  The vulnerability described
in Adam's paper has nothing to do with the Upgrade handshake -- they
specifically did not test the actual handshake.  What they did is test the
post-handshake non-encrypted connection for intercept proxies that might
(in 8 out of 47,338 cases) mistakenly interpret the unencrypted channel
after the handshake is completed (or ignored).  Thus, it represents
an attack on any non-opaqued channel that is being scanned by caching
intercept proxies (an architecture that is not condoned by HTTP but does
occur in some limited practice by idiots) when a browser is allowed to
send arbitrary bytes over that channel.

One question, therefore, is whether it is important to protect the 0.0169%
of users behind networks that are deliberately using an insecure and invalid
form of HTTP proxy from yet another attack based on that invalid usage.

If it is important, then the solutions are

  a) never use low-numbered ports for websockets [my preference]

  b) obfuscate the data sent via websockets in some way that the client
     page cannot control or deceive. [e.g., encryption, gzip with a fixed
     dictionary, or escaping LF in data.]

  c) establish post-handshake framing that prevents subsequent data
     from being interpreted as an HTTP request or response.
     [e.g., inserting a 'W' after every LF in data.]

Note that none of the above has anything to do with Upgrade or the method used
in the initial exchange.  Labeling the paper as discovering a vulnerability in
the Upgrade handshake is misleading and unethical.

Adam's solution (and EKR's usual hammer) is to use TLS encryption.  That is
fine when it satisfies the protocol use cases, but not so great when it

A more sensible test would have been to use a new method, like WEBSOCKET,
since then at least the initial handshake could remain HTTP-compliant.

BTW, Upgrade was not designed for establishing TLS connections.  Some people
tried to use it that way, three years after it was designed for HTTP/2+,
and failed to get any adoption because Upgrade is hop-by-hop and that's not
what users want from a TLS encrypted stream.  Likewise, using CONNECT to
establish secure tunnels through proxies fell out of favor a long time ago.
The practice of moving such tunnel-oriented behavior onto a separate port has
the benefit of relieving the non-encrypted infrastructure from having
to deal with the very different behavioral and resource-intensive
characteristics of secure connections, which is why I prefer (a) above
whether or not we use TLS (websockets are not the web and do not belong
on port 80).

BTW2, "transparent proxy" != "intercept proxy".  A proxy is called transparent
when it doesn't transform the messages exchanged, unlike intercepts (which
aren't even true proxies since they are unknown to the client).  Please use
the correct terminology.