Ian Hickson wrote:
On Wed, 15 Jul 2009, Amos Jeffries wrote:
Could you elaborate on what bytes Squid thinks it should change in the
WebSocket handshake?
Byte 5 through to the first of: two CRLF or one NULL byte. Specified as
step 1 through 11 by the looks of it.
Correctly operating:
* MUST remove the "Upgrade: WebSocket\r\n" bytes.
[...]
This would cause the WebSocket connection to fail, which is the correct
behaviour. After all, if the connection isn't upgraded, we don't want
anything further to happen (in particular we don't want the client sending
arbitrary bytes to the server or proxy, since that would open up the proxy
to being abused to download content from any arbitrary server including
intranet servers or other domains on shared-hosting servers).
So loosening up the handshake wouldn't solve the problem described
previously of Squid breaking an HTTP Upgrade to WebSocket in the case of a
client behind a firewall that only allows port 80 and where all traffic
through that port goes through a man-in-the-middle proxy.
What solution would you recommend for such a case?
a) Getting a dedicated WebSocket port assigned.
* You and the client needing it have an argument to get that port
opened through the firewall.
* Squid and other proxies can be altered to allow CONNECT through to
safe defined ports (80 is not one). Or to do the WebSocket upgrade itself.
b) accepting that the network being traversed is screwed beyond
redemption by its own policy or admin.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
Current Beta Squid 3.1.0.9
