Subject: [hybi] draft-abarth-websocket-handshake-00

From: Adam Barth <[email-masked]>
Date: Mon, 18 Oct 2010 03:49:24 -0700

I've taken the liberty of writing up Eric and my handshake proposal as
an Internet draft:

http://www.ietf.org/id/draft-abarth-websocket-handshake-00.txt

This draft is heavily based on
draft-ietf-hybi-thewebsocketprotocol-03.  In particular, I just sliced
out Section 5 of that draft and edited it to describe the new
proposal.  It's obviously very rough editorially, but hopefully it
will be useful to have a concrete basis for conversation.

Kind regards,
Adam

---

From: James Graham <[email-masked]>
Date: Mon, 18 Oct 2010 21:33:20 +0200 (CEST)

> will be useful to have a concrete basis for conversation.

This looks really useful Adam, thanks.

Do we have some sense of where we are with respect to this handshake 
proposal? I have the general sense that a majority of people, but not 
everyone, feel that the basic design is better than the -03 handshake. Is 
that wrong? In particular the thread that Eric started suggested broad 
agreement that obfuscating user-supplied data is an good approach to 
preventing cross-protocol attacks.

There are still clear disagreements on obfuscating everything 
vs allowing certain pieces of routing information to pass through in the 
clear. Is this something where we need to make an informed tradeoff, or is 
there some experiment we can run to determine the best option? The same 
question applies to using CONNECT since some people seemed concerned about 
this part of the proposal.

In general it would be good if we can avoid a situation where browsers 
upgrade to the new framing and then have to change again for a handshake 
change.

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 18 Oct 2010 13:37:40 -0700

On Oct 18, 2010, at 12:33 PM, James Graham wrote:

> Do we have some sense of where we are with respect to this handshake proposal? I have the general sense that a majority of people, but not everyone, feel that the basic design is better than the -03 handshake. Is that wrong? In particular the thread that Eric started suggested broad agreement that obfuscating user-supplied data is an good approach to preventing cross-protocol attacks.
> 
> There are still clear disagreements on obfuscating everything vs allowing certain pieces of routing information to pass through in the clear. Is this something where we need to make an informed tradeoff, or is there some experiment we can run to determine the best option? The same question applies to using CONNECT since some people seemed concerned about this part of the proposal.

I really liked Eric's division of the handshake proposal into three mostly-separable concerns. It seems like the first, masking payload data (as opposed to routing data) has been discussed thoroughly and there do not seem to be strong objections remaining. It would be good to have similar discussions for the other two aspects.

Also, it might be useful to have tracker issues for those three sub-proposals.

Regards,
Maciej

---

From: Brodie Thiesfield <[email-masked]>
Date: Tue, 19 Oct 2010 08:15:16 +0900

I appreciate the concern of cross protocol attack once the binary
WebSocket packets start flowing on the connection, however I do not
see how the use of a real HTTP Upgrade (or CONNECT) is any less secure
than any other standard HTTP request.

The server and intermediaries processing the initial WebSocket request
is either:
* a HTTP capable server that sees millions of these requests both good
and malformed and has been dealing with them for years
* a non-HTTP server that already needs to deal with GET/POST HTTP
requests from attacking browsers with arbitrary header/key pairs

By using a bog standard HTTP GET+Upgrade or CONNECT initial request,
it allows us to continue using existing HTTP infrastructure.
Connections to the desired virtual host and resource selection via the
URL is still possible. If the possible endpoints are restricted by the
WebSocket spec to ports >1000, then browser attacks using WS on DNS
etc can be made essentially moot.

Once the connection has been upgraded (or CONNECT'ed), then change to
using an obfuscated stream, but changing the protocol before that
appears to gain nothing but loses much. Of course, support can be
added for a new protocol like what is suggested, but we all know that
software upgrades just don't happen that often.

I propose that a combination of the existing HTTP Upgrade using Greg's
suggestions to make it fully HTTP compliant (or a no-frills HTTP
CONNECT request), with Adam's ideas for obfuscation of the byte stream
after the 101/connect is completed.

GET /desired/url HTTP/1.1
Host: virtual.example.com
Connection: Upgrade
Upgrade: WebSocket
Sec-WebSocket-Key: jiminy
Sec-WebSocket-Protocol: chat superchat
...
CRLF

101 Sure
Sec-WebSocket-Key: cricket
Sec-WebSocket-Protocol: superchat
...
CRLF

obfuscated bytes

Regards,
Brodie

On Tue, Oct 19, 2010 at 5:37 AM, Maciej Stachowiak <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: John Tamplin <[email-masked]>
Date: Mon, 18 Oct 2010 19:40:16 -0400

> etc can be made essentially moot.

Since one of the primary use cases is to run the WebSocket server on the
same port as the HTTP/HTTPS server, that would not be feasible.

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

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 19 Oct 2010 10:42:15 +1100

I have several concerns about this proposal.

Firstly there is the style of the draft.  It is again back to very
algorithmic specification of something that looks like a HTTP CONNECT
request, but perhaps is not. We have debated this endlessly before and
the consensus was that we must be HTTP compliant before the handshake
completes. Thus the specification should be written to explicitly talk
about sending a HTTP CONNECT request, not about sending bytes that
look like a HTTP CONNECT request.

With regards to the handshake itself, I remain very cautious about the
usage of CONNECT.  I would like to see some evidence that a connect to
an invalid HOST is not going to break existing transparent proxies.

If CONNECT is workable, then I believe that all the handshake
fields/data should be sent  either as  encoded header values of the
HTTP request/response or as WS frames (ping, pong or hello). It is
overly complex to have a connection that firstly uses HTTP, then some
unframed data and finally WS frames.  This is specially true for
asynchronous implementations that can't simply block and read the
unframed data.

regards

On 19 October 2010 06:33, James Graham <[email-masked]> wrote:
> There are still clear disagreements on obfuscating everything vs allowing
> certain pieces of routing information to pass through in the clear. Is this
> something where we need to make an informed tradeoff, or is there some
> experiment we can run to determine the best option? The same question
> applies to using CONNECT since some people seemed concerned about this part
> of the proposal.
>

---

From: Brodie Thiesfield <[email-masked]>
Date: Tue, 19 Oct 2010 08:42:43 +0900

> same port as the HTTP/HTTPS server, that would not be feasible.

Specify exceptions for ports 80 and 443. The proposal for restricting
endpoints was echoed from someone else, I didn't see much discussion
from it, but it isn't necessary and doesn't change the essential
argument.

Regards,
Brodie

---

From: Adam Barth <[email-masked]>
Date: Mon, 18 Oct 2010 16:52:16 -0700

> look like a HTTP CONNECT request.

Oh, I should have mentioned that I just copied the same style as -03.
I agree that it would be helpful to present this in a more readable
form.

> asynchronous implementations that can't simply block and read the

We can put the "unframed data" in an HTTP header if you like.  The
only complexity with that approach is we'll need to encode it into
ASCII, perhaps using base64.

If I controlled the world, I'd use an encrypted JSON blob in an HTTP
header rather than colon/CRLF delimited fields, but I understand that
might not be fashionable in some circles.

Adam

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 18 Oct 2010 17:03:21 -0700

> look like a HTTP CONNECT request.

+1

> an invalid HOST is not going to break existing transparent proxies.

If the request does not use normal HTTP server dispatching with a normal 
HTTP Host/URL, please do not use the HTTP port.

If we are not reusing any of the existing HTTP server infrastructure, 
there's no value added in using the HTTP port.

-- Scott