Re: Hello from Mozilla

fre 2009-07-17 klockan 10:00 +0000 skrev Ian Hickson:

> 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.

The HTTP/1.x 101[...]Upgrade: WebSocket[CR][NL][...][CR][NL][CR][NL]
sequence is pretty stringent imho, without hardcoding the exact sequence
at octet level, where [...] is any sequence of ascii characters except
for [CR][NL][CR][NL]

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

Because it's designed to also talk to a web server, and if I understand
your intended use case those clients will by nature almost certainly
also be HTTP clients, or at least embedded in HTTP clients.

> The only case I can see where the handshake gets changed is MITM proxies,
> but as far as I understand it, there's no way to ever get a reliable
> bidirectional non-HTTP TCP/IP connection through a Squid MITM proxy over
> port 80 to a remote server that normally acts like an HTTP server, so it
> doesn't matter anyway, since whatever we do, it won't work on that port.

The relevant use case you need to make sure to support in specification
is

client -> HTTP Surrogate -> Internal origin

don't bend over too much for transparently intercepting proxies, it's
not your job to specify how those should behave.

> Is there a way to get a reliable bidirectional non-HTTP TCP/IP connection
> through a Squid MITM proxy over port 80 to a remote server that normally
> acts like an HTTP server?

As I already said, generally no. But at some point transparently
intercepting Squids will have the option to switch to tunnel mode when
seeing non-HTTP traffic on port 80 (missing the HTTP signature), and at
the same time forwarding of Upgrade requests is likely to be
implemented.

> If not, then sending any data over port 80 on such a network wouldn't
> work, right? So as far as I can tell, port 80 in such a scenario isn't
> relevant. Authors in such scenarios would use port 443, like Mark said.

Correct.

> 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.

Which is the point I have been making all the time. As that is processed
by HTTP stacks your protocol need to be prepared to deal with the
aspects that the HTTP stack may introduce on you

  - HTTP authentication with it's set of status codes and HTTP headers
  - Via headers
  - Reordering of headers
  - Possible addition of Date headers in responses
  - Custom headers added to the request/response
  - And maybe other similar things as well

Up until the 101 response has finished the sequence is HTTP and if your
intention is that this should be processed by HTTP infrastructure then
you need to accept it being HTTP.

> I don't understand the relevance of your question. It doesn't matter what
> you're talking; in the case of a MITM proxy, the client doesn't know it
> isn't talking straight to the server. Talking HTTP more than we already do
> doesn't suddenly mean we can get a two-way pipe set up.

Talking proper HTTP means the MITM will handle it for you assuming the
MITM can handle HTTP/1.1 properly.

Sure, Squid can not yet, and we don't claim Squid to be HTTP/1.1 either
as we don't like lying about our capabilities. But we will at some not
too distant point in time.

> I really don't understand the problem you are alluding to here. What needs
> upgrading in such a scenario?

The company infrastructure sitting between Internet and the web
server(s) in question where some webmaster want's to deply a WebSocket
application needs to add support for the WebSocket protocol, which is
one of the primary things people who wants to run stuff like this over
port 80 want to avoid.. To them the WebSocket communication is just part
of the web application, not a separate entity which lives it's own life
requiring it's own infrastructure in firewall rules, load balancers,
servers etc.

Regards
Henrik
Received on Fri Jul 17 2009 - 11:29:19 MDT