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
