Re: Hello from Mozilla

On Fri, 2009-07-17 at 10:00 +0000, Ian Hickson wrote:
> On Fri, 17 Jul 2009, Adrian Chadd wrote:
> > 2009/7/17 Ian Hickson <ian_at_hixie.ch>:
> > >> That way you are still speaking HTTP right until the "protocol
> > >> change" occurs, so any and all HTTP compatible changes in the path(s)
> > >> will occur.
> > >
> > > As mentioned earlier, we need the handshake to be very precisely
> > > defined because otherwise people could trick unsuspecting servers into
> > > opting in, or rather appearing to opt in, and could then send all
> > > kinds of commands down to those servers.
> >
> > Would you please provide an example of where an unsuspecting server is
> > tricked into doing something?
>
> Sure.
>
> Suppose we had no handshake at all, and that there was no data framing, so
> that as soon as we connected to a port, we could send arbitrary data down.
>
> A Web page, say evil.example.net, could open a Web Socket connection to
> http://www.corp.example.com/, send it a GET request for /secret-plans, and
> then forward the contents of the file to a remote host. If they could then
> trick someone on example.com's intranet to look at this file, and assuming
> www.corp.example.com did nothing more than rely on connectivitity for
> authentication (pretty common in small intranets), then evil.example.net
> could steal the company's secret plans.

Can't the web page just send an ajax request to corp.example.com anyway?
And if it can't, why doesn't the same browser security model prevent
websockets being used in the same way?

> Now, Web Socket has a multi-layered approach to dealing with this.
>
> - there is the handshake, which requires that the server respond with a
> very specific set of bytes, thus guaranteeing that the server is in fact
> WebSocket-aware. Any "wildcard" part to this handshake increases the risk
> that there will be a server somewhere that can be tricked. For example, if
> the handshake were "HTTP" followed by anything followed by "WebSocket",
> then some HTTP servers could be tricked into doing the handshake -- for
> example, the response to "GET /WebSocket" on the ietf.org host (not
> www.ietf.org) includes the word WebSocket in the response.
>
> HTTP servers aren't the only concern, of course; we want the handshake to
> be as secure as possible against any other protocol that may exist on any
> server that may be deployed. We don't know what's out there (especially in
> intranets), so the handshake has to be pretty stringent to make it as
> unlikely as possible.

Dumping the ability to look like HTTP altogether is your best bet IMO:
even on port 443. For port 443, someone running a websocket server
should just not run an HTTPS server there. Or define port 815 as
websocket/s.

> - there is origin checking and location checking, and the location
> checking isn't just an echo of the original request's data. This makes
> causing the server to send back particular data harder. (It's also part of
> our cross-origin security model and our shared hosting support; but that's
> a separate discussion.)
>
> - there is the framing, which does provide a modicum of protection by
> forcing another byte in front of the first author-controlled packet sent.
> (This isn't really a security feature, it's just a lucky accident of the
> framing that we needed to turn TCP streams into packets.)

To summarise, if I have it right, you want to make sure that *the
browser* can be sure that corp.example.com really was intending to be a
websocket server when it opened the connection. If its not, it should
bail. That seems reasonable :). We can definitely (and have been :))
advising on how to do that with HTTP, but it means *having a decent HTTP
stack*. The response to a HTTP request is always an HTTP response.
Upgrade: changes the way the wire behaves after that.

> Yes, but the client is a WebSocket client, not an HTTP client, so why
> would it send anything but the WebSocket handshake?

Because its asking an HTTP server to upgrade. That makes it an HTTP
client and a WebSocket client... as in fact you note below ..

..
> No. I'm intending to do stuff over port 81. There is a desire in certain
> cases to be able to share this traffic with servers running on port 80,
> and in those cases, the content sent and the content required to be
> returned by the server is valid HTTP until the Upgrade succeeds, at which
> point it isn't HTTP.

> > Ian, are you absolutely certain that everywhere you use "the internet",
> > there is no "man in the middle" between you and the server you're
> > speaking to?
>
> In the case of TLS connections, yes.

In corporate networking, TLS MITM is a 'feature': company signed
certificates are used to sign the TLS connection to the corporate
firewall, and the firewall validate the SSL connection to the outside
world. I haven't personally used this, so can't really say much more
about it. Squid's ssl-bump feature can be used for this, but I believe
browser config is needed (again on a corporate basis) to tell it that
this is expected.

-Rob