Subject: Re: [hybi] Feedback on thewebsocketprotocol-22

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Aug 2009 20:44:38 +1000

On 30/07/2009, at 9:39 AM, Ian Hickson wrote:

> On Fri, 17 Jul 2009, Mark Nottingham wrote:
>>
>> * I've already given feedback on the squid-dev list ("Hello from
>> Mozilla" thread on
>> <http://www.squid-cache.org/mail-archive/squid-dev/200907/>)  
>> regarding
>> the handshake and impact on HTTP infrastructure. I think all that's
>> necessary here is some added text about the failure cases (which I  
>> think
>> you're already starting to address in -23)
>
> Is the text adequate now?

Yes.

> and some adjustment to the text in the introduction (e.g., a pointer  
> to
>> the new section outlining the trade-offs/risks).
>
> Since the two sections are on the same page, I haven't added the  
> pointer
> -- someone reading the spec will see both sections soon enough.

Ack.

> * 1.1 Security model: you frame the model in terms of browsers and Web
>> pages. I think Websockets is potentially applicable to any restricted
>> execution environment, not just Web pages.
>
> It would have to be an execution environment that uses an Origin-based
> security model. I'm not aware of any other such mechanisms. Could you
> elaborate on what you would like the spec to say here?

s/(not from a Web page)/(not from a Web page or other environment with  
an Origin-based security model)/

>> * 3.1 Handshake: host, port, origin and resource name all need
>> definitions/references. Without them, it's difficult to tell what the
>> allowable ranges are; e.g., can a host contain non-ASCII characters?
>
> There's no allowable ranges -- this is just defining the protocol  
> side of
> the API spec, which invokes this algorithm. These are just  
> "parameters" or
> "variables", they aren't expected to be arbitrarily invoked.

I don't know if I buy that. You already define /host/ and /origin/ as  
strings (because they're lowercased), and they're used as input into  
protocol paramaters which do have concrete and well-defined ranges.

> I suppose I could add a separate section on "how to use this  
> specification
> from another specification", where I define what the expected ways  
> that
> the algorithms in this spec are to be invoked are. Would that help?

Regardless of the issue above, I think that would be helpful.

> * 3.1 Handshake, step 2: Can you speak to why this is limited to a  
> host,
>> and not (host, port)?
>
> Aren't system resources usually limited on a per-host basis, not per- 
> port?
> I can make it port-limited if you think that's the better thing for  
> DOS
> protection. I'm not an expert on this topic, by any means.

When there are load balancers, firewalls and other types of  
intermediaries present, it's per-port. A "host" is often an artificial  
construct.

> * 3.1 Handshake, step 3: Another thing to consider here is how
>> WebSockets should be accommodated in proxy.pac; it's commonly used.
>> E.g., define a new proxy type WEBSOCKETS in proxy.pac, and define a
>> fallback to SOCKS then HTTPS then HTTP if it's not present.
>
> Good point. What's the spec for proxy.pac? I should probably just  
> update
> that directly.

Unfortunately, it's not standardised, or even well-defined.

The original spec is:
  http://web.archive.org/web/20060424005037/wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

Thinking about it, I *believe* it should be possible to handle  
websockets without changing the format, however; assuming that it has  
a new URL scheme, the url passed to FindProxyForURL should contain  
enough information, and the DIRECT, PROXY and SOCKS return values  
should do the trick (keeping in mind that PROXY indicates an HTTP  
proxy).

Of course, this will require changes both in the UA and in proxy.pac  
scripts, but not in the proxy.pac format itself.

On a related note, if I read text in the 3.1 step 3 correctly:
> If the user agent is configured to use a proxy when using the Web  
> Socket protocol to connec
this implies that UAs will eventually have a separate "websocket"  
configuration type for manual proxy config, no?

> * 3.1 Handshake, step 3: "If there was a password" --> "If proxy
>> authentication [RFC2616] is used"
>
> That's just non-normative example text, I try to keep the example text
> colloquial so as to make the examples clearer to new readers.

OK.

> * Overall, at the risk of beating a dead horse, the algorithmic nature
>> of this specification makes it difficult to answer questions about  
>> the
>> protocol without building a state machine. I'd suggest that adding a
>> section or two about the overall operation of the protocol and its
>> various structures would help address this concern.
>
> I've added an introduction to the algorithm. Does it address your
> suggestion adequately?

It's better.

> * Finally, AIUI the important features that WebSockets adds (Origin,
>> assuring that other protocols aren't simulated, etc.) all happen  
>> during
>> the handshake. As such, I wonder why this specification isn't just  
>> the
>> handshake, falling back to a normal (possibly tunneled) TCP/IP
>> connection once the handshake has completed; it would be a lot less  
>> new
>> things to understand and vet, and less constraining as well.
>
> The framining is present so that we can expose this as an event-based
> protocol instead of a streaming-based protocol in the API. It would  
> be a
> pain to require authors to have to implement buffering and piecing
> together of messages when we can just do it with trivial framing at  
> the
> API level.

It may be worth mentioning this in the introduction; it's likely to  
come up again.

One more thing; you currently specify that the host header is sent  
with just the /host/ value. HTTP requires that if the port is not the  
default for the given protocol, it needs to be part of the Host header  
as well.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 12 Aug 2009 13:56:53 +0100

> elaborate on what you would like the spec to say here?

On that note, is the Origin model used for WebSockets the same as that
in Cross-Origin Resource Sharing, http://www.w3.org/TR/cors/ ?

If they are basically the same, shouldn't WebSockets be using the same
pre-flight check mechanism, instead of the verbatim byte sequence
which looked (to me) rather fragile?

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Sun, 16 Aug 2009 09:17:50 +0000 (UTC)

On Wed, 12 Aug 2009, Mark Nottingham wrote:
> > > 
> > > * 1.1 Security model: you frame the model in terms of browsers and 
> > > Web pages. I think Websockets is potentially applicable to any 
> > > restricted execution environment, not just Web pages.
> > 

Like what?

> > > definitions/references. Without them, it's difficult to tell what 
> > > the allowable ranges are; e.g., can a host contain non-ASCII 
> > > characters?
> > 
> > There's no allowable ranges -- this is just defining the protocol side 
> > of the API spec, which invokes this algorithm. These are just 
> > "parameters" or "variables", they aren't expected to be arbitrarily 
> > invoked.
> 

I've tweaked the algorithm so that the inputs are unrestricted within the 
realm of valid values given the types that they represent (host, port, 
etc), except that resource name must start with a "/", which I've 
mentioned explicitly. Let me know if you would like it tweaked further.

> > specification from another specification", where I define what the 
> > expected ways that the algorithms in this spec are to be invoked are. 
> > Would that help?
> 

Done.

> > > host, and not (host, port)?
> > 
> > Aren't system resources usually limited on a per-host basis, not 
> > per-port? I can make it port-limited if you think that's the better 
> > thing for DOS protection. I'm not an expert on this topic, by any 
> > means.
> 

Sure, but if we make it {host,port}, then _only_ load-balanced sites are 
protected, and normal sites are vulnerable to people just port-spamming 
them. Surely that's a more serious problem anyway, since the load-balanced 
sites are more likely to be protected against DOS attacks?

In any case, if we protect against just per-host attacks, that also 
protects the load-balanced sites, no?

> > update that directly.
> websockets without changing the format, however; assuming that it has a 
> new URL scheme, the url passed to FindProxyForURL should contain enough 
> information, and the DIRECT, PROXY and SOCKS return values should do the 
> trick (keeping in mind that PROXY indicates an HTTP proxy).
> 

I've added text about handling proxy autoconfiguration scripts.

> configuration type for manual proxy config, no?

It handles the case where they do. Whether they do or not is up to them.

> > > during the handshake. As such, I wonder why this specification isn't 
> > > just the handshake, falling back to a normal (possibly tunneled) 
> > > TCP/IP connection once the handshake has completed; it would be a 
> > > lot less new things to understand and vet, and less constraining as 
> > > well.
> > 
> > protocol instead of a streaming-based protocol in the API. It would be 
> > a pain to require authors to have to implement buffering and piecing 
> > the API level.
> It may be worth mentioning this in the introduction; it's likely to come 
> up again.

I've added a paragrah in the last intro section.

> One more thing; you currently specify that the host header is sent with 
> just the /host/ value. HTTP requires that if the port is not the default 
> for the given protocol, it needs to be part of the Host header as well.

Fixed.

(Why does HTTP require that? Can't the server easily determine what port 
was in fact used? What happens if the port sent in the Host: doesn't match 
the actual port used?)

On Wed, 12 Aug 2009, Jamie Lokier wrote:
> Ian Hickson wrote:
> > > * 1.1 Security model: you frame the model in terms of browsers and 
> > > Web pages. I think Websockets is potentially applicable to any 
> > > restricted execution environment, not just Web pages.
> > 

Assuming you mean this one:

   http://dev.w3.org/2006/waf/access-control/

Then no, not quite.

> pre-flight check mechanism

No, CORS is far more complicated than is needed here.

> instead of the verbatim byte sequence which looked (to me) rather 
> fragile?

Could you elaborate on why it would be fragile?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 16 Aug 2009 18:17:04 +0100

Ian Hickson wrote:
> was in fact used?

The port may have been forwarded to a different port by a router doing
port rewriting, just as it can do address rewriting.

> What happens if the port sent in the Host: doesn't match 
> the actual port used?)

The Host: indicates the client's point of view.  It's up to the server
to decide if it has resources at http://foobar.example.com:12345/ and
if it would accept a request on an IP address or port number which is
different at the server.

>    http://dev.w3.org/2006/waf/access-control/

What are the logical differences?

> No, CORS is far more complicated than is needed here.

If you discard all the stuff about request methods (GET/POST) and
requests which don't need a pre-flight check:

The pre-flight check asks a server "do you support this new type of
request I'd like to do - I won't do it if you don't recognise my question".

That strikes me as a good way to check for WebSockets functionality, too.

Even though you wouldn't use CORS, the method of doing the pre-flight
check (and caching the result) could be much the same.
 
> Could you elaborate on why it would be fragile?

Unavoidable proxies can modify it, even in trivial ways like
reordering headers or altering the HTTP version number, as well as
adding Via (though not all do that).

- Intercepting proxies are used by many large ISPs and
  instutitional/corporate locations.  These intercept requests on port
  80, so cannot be avoided except by using another port.  They are
  mostly invisible to HTTP traffic except that they add caching.  Some
  of them will modify the verbatim byte sequence.

- At some places alternative ports are blocked, so you must go through
  the intercepting proxy on port 80.

- Explicit proxies are also used in lots of places, especially where
  client configurations are controlled centrally, and again, sometimes
  there is no other way to reach the public internet so you have to
  use the proxy.

It's quite clear that when going through such a proxy, it's unlikely
that the WebSockets protocol would work.  However it seems a poor
match to use this as a method of detecting that, because sometimes it
would pass the request unchanged.

-- Jamie

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Aug 2009 14:03:14 +1000

>> an Origin-based security model)/

One that doesn't exist yet...

> protects the load-balanced sites, no?

I suppose my objection here is largely that most similar mechanisms in  
the network world operate at a port level... I'm not strongly against  
doing it at the host level, but it just seemed odd. Anyone else have  
this feeling?

---

From: Jeff Walden <[email-masked]>
Date: Thu, 20 Aug 2009 16:49:04 -0700

> scripts, but not in the proxy.pac format itself.

This is correct; a draft implementation of WebSockets for Mozilla piggybacks on the HTTP server and proxying hacks we use for automated testing in this manner, and it does work perfectly well with changes to the PAC script.

Jeff