Subject: [hybi] CONNECT vs UPGRADE as method for handshake

From: Salvatore Loreto <[email-masked]>
Date: Sun, 07 Nov 2010 18:22:28 +0200

Hi there,

in order to make some progress on the handshake design,
I think it would be good to discuss as proposed while ago by Eric Rescola
(http://www.ietf.org/mail-archive/web/hybi/current/msg04431.html)
and more recently by Bjoern Hoermann 
(http://www.ietf.org/mail-archive/web/hybi/current/msg04539.html)

which method we want to use in the handshake

1) CONNECT

or

2)  UPGRADE

Both methods have positive features but also negative aspects that need 
to be solved
to make the handshake successful and secure as much as possible.
So decide which method to use will help the wg to focus on just one 
method and
it will also speed up the design of the new handshake.

As chairs Joe and I are interested in your opinions and preference 
supported by the technical
reasons/opportunities for you preference.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Zhong Yu <[email-masked]>
Date: Sun, 7 Nov 2010 12:38:22 -0600

What type of intermediary will work with CONNECT but not UPGRADE when
a WebSocket stream flows through it?

If there is no such intermediary, then UPGRADE seems to have more power.

- Zhong Yu

On Sun, Nov 7, 2010 at 10:22 AM, Salvatore Loreto
<[email-masked]> wrote:
> Both methods have positive features but also negative aspects that need to
> be solved
> So decide which method to use will help the wg to focus on just one method
> and
> As chairs Joe and I are interested in your opinions and preference supported
> by the technical
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 7 Nov 2010 20:14:20 +0100

> a WebSocket stream flows through it?

One year ago I would have said "some of them". Basically those which
support being installed in front of proxies (think load balancers), and
which did never have to support Upgrade. Now that almost one year has
elapsed with WebSocket requiring Upgrade, I think that most products
where it was easy enough have implemented it. It does not mean they're
deployed but at least a version should be ready.

Speaking from my experience, I have implemented support for Upgrade in
haproxy after having understood its specific behaviour on this WG.

> If there is no such intermediary, then UPGRADE seems to have more power.

It's more flexible and closer to standard usage, as it's the server-side
of CONNECT which was made for proxies.

Regards,
Willy

---

From: Zhong Yu <[email-masked]>
Date: Sun, 7 Nov 2010 14:24:13 -0600

> support being installed in front of proxies (think load balancers), and

In that case, don't we have another, "normal" CONNECT head in front of
the WS CONNECT head?

Since Adam's CONNECT(WS) head contains no useful information that a
WS-agnostic intermediary can use, if the intermediary does pass though
CONNECT(WS), it most likely would allow any TCP connections pass
through - therefore UPGRADE would work too.

Unless the intermediary specifically looks for CONNECT(HTTP) - but
then it's probably a proxy or friend of proxy, and both CONNECT(WS)
and UPGRADE as payload will pass through.

So I'm very curious about an example where CONNECT(WS) works but not UPGRADE.

- Zhong

---

From: Zhong Yu <[email-masked]>
Date: Sun, 7 Nov 2010 14:35:41 -0600

Sorry - I see you are talking about something that supports proxy but
not installed in front of proxy. If it's installed very close to
server, it's within the control of those who deploy WS servers.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 8 Nov 2010 13:49:34 +1100

Sal,

CONNECT vs UPGRADE  is  a difficult question to answer in isolation.

I would prefer a HTTP compliant CONNECT handshake (without obfuscated
host) to an -76 style UPGRADE handshake.

But I would prefer a HTTP compliant UPGRADE to a CONNECT handshake
with obfuscated routing information.

For me, the decision comes down to the following criteria in priority order:

0) Security - there has to be no demonstrable exploits.

1) If it is running on the HTTP ports, it has to be HTTP compliant
before the WS connection is established. This includes respecting
normal routing headers (eg Host headers).   If it is not HTTP
compliant, it is a non starter for me.

2) Which gets through a significant majority of intermediaries and networks

3) Security in depth - which has the most robust security in the face
of poor server implementations.

4) complexity

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 07 Nov 2010 20:11:12 -0800

Consolidating replies...

> If there is no such intermediary, then UPGRADE seems to have more power.

Power is not the only consideration. The other consideration is, how likely is it for an intermediary to be confused in a dangerous way when it doesn't understand the handshake? The CONNECT-based upgrade has less risk in that regard.

However, there is some evidence that CONNECT succeeds slightly more often.

> deployed but at least a version should be ready.

Looking at currently deployed infrastructure as opposed to future plans, Adam Barth posted preliminary data showing that the CONNECT-based handshake succeeds slightly more often than the Upgrade-based handshake. It is also (according to this data set) less likely to leave the connection in a confused state where it is not actually working but has not failed either.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 07 Nov 2010 20:13:57 -0800

> with obfuscated routing information.

That's a good point. I believe Eric previously split the question into three parts, using CONNECT, masking routing information, and masking payload data. From what you say above, it sounds like you agree with using CONNECT, but do not agree with masking routing information.

Perhaps we can have a separate thread specifically about masking routing information.

Regards,
Maciej

---

From: Zhong Yu <[email-masked]>
Date: Fri, 12 Nov 2010 12:03:09 -0600

How about CONNECT + Upgrade?

 CONNECT example.com:80 HTTP/1.1
 Host: example.com
 Upgrade: WebSocket

CONNECT and "Host" usages follow existing conventions. "Upgrade:
WebSocket" is simply to flag the connection as WS.

WS server must respond with

 HTTP/1.1 200 OK
 Upgrade: WebSocket

That takes care of the tunneling part. The meat of WS handshake should
be done in the next two WS frames. A pure WS server doesn't need to be
HTTP savvy. It can treat the HTTP request part as historical magic
bits that ends with \r\n\r\n, bypass and ignore it, and return the
fixed HTTP response as another historical magic bits. After that, the
"real" WS handshake is done in the WS language.

- Zhong Yu

---

From: Zhong Yu <[email-masked]>
Date: Fri, 12 Nov 2010 12:18:02 -0600

> bits that ends with \r\n\r\n, bypass and ignore it, and return the

scratch that. that's a really bad idea. the server must validate
something in the HTTP request to make sure it's from a WS client.