[squid-users] Help! Squid Host header rewriting

[Amos Jeffries]

On 20/11/2015 3:29 a.m., LauranceKuo wrote:
> Thanks for the quick response.
> 
> I quoted the link to show my problem. Below is the detail.
> 
> First, the version of Squid I am using is 3.5.4.
> 
> And, this is the http request from client to Squid:
> /GET
> http://122.228.56.30/snsvideodownload?filekey=30270201010420301e0201660402534804100d9d070ab465cfc2259e39ffd4a63cad020303f7550400&bizid=1023&hy=SH&fileparam=302f0201010428302602044c9650540204564dcc5b02024eea02031e867502030f42400204b01ba80a0204f75de2650400
> HTTP/1.1
> Host: vweixinf.tc.qq.com
> .../
> 
> and, this is the http request from Squid to server:
> /GET
> /snsvideodownload?filekey=30270201010420301e0201660402534804100d9d070ab465cfc2259e39ffd4a63cad020303f7550400&bizid=1023&hy=SH&fileparam=302f0201010428302602044c9650540204564dcc5b02024eea02031e867502030f42400204b01ba80a0204f75de2650400
> HTTP/1.1
> Host: 122.228.56.30
> .../
> 
> and the server responses with:
> /HTTP/1.1 404 Not Found/
> 
> And the client is WeChat, which is a very popular APP in China. I can't tell
> them to correct this.

You can ask. Like any software they have incentive to fix it and get
their software working in more networks.

PS. Squid is also popular software. China is only one of many countries
whose HTTP traffic is relayed wholly by Squid. And the HTTP in/out of
China is surprisingly small compared to the countries population size.


But you first need to be sure it is their software and not something
else on the delivery path between QQ and Squid.

This type of raw-IP in URL with textual Host header can be the output of
other proxy/router/loadbalancer software or devices doing traffic
interception and wrongly using that type of output message as their
broken attempt at fixing CVE-2009-0801.


> So is there a way to keep this http request the same?

Not without breaking the Internet.

These are the mandatory ("MUST") requirements placed on Squid :

RFC 7230 (HTTP/1.1)
"
   If the target URI includes an authority component, then a
   client MUST send a field-value for Host that is identical to that
   authority component, ...
"

NOTE: The 'authority component' in the URI is the raw-IP part
(122.228.56.30). On the outgoing connection Squid is the client /
sender. QQ or whatever is sending that message to Squid is violating
this mandatory requirement in its own role as client.

"
   When a proxy receives a request with an absolute-form of
   request-target, the proxy MUST ignore the received Host header field
   (if any) and instead replace it with the host information of the
   request-target.  A proxy that forwards such a request MUST generate a
   new Host field-value based on the received request-target rather than
   forward the received Host field-value.

   Since the Host header field acts as an application-level routing
   mechanism, it is a frequent target for malware seeking to poison a
   shared cache or redirect a request to an unintended server.  An
   interception proxy is particularly vulnerable if it relies on the
   Host field-value for redirecting requests to internal servers, or for
   use as a cache key in a shared cache, without first verifying that
   the intercepted connection is targeting a valid IP address for that
   host.

   A server MUST respond with a 400 (Bad Request) status code to any
   HTTP/1.1 request message that lacks a Host header field and to any
   request message that contains more than one Host header field or a
   Host header field with an invalid field-value.
"


There are a lot of apps that do similar odd things to what you are
seeing, but in the opposite direction, like put raw-IP or unusual port
numbers in the Host header. They would all break in the same sort of way
you are seeing here, and there are more of them in wider use than QQ.
Then there are all the apps that use Host like "localhost" or "Home"
(grumble).

Then that security vulnerability I referenced in the original thread way
back, and all the malware trying to use it. One of the things behind
that specification warning. The Host header is completely open to
control by third-party attackers. I refer here not to the client or the
app they are using but to anyone writing embedded adverts or web pages
it is displaying.
The danger is amazingly big for such a simple thing - amongst the side
effects are problems such as bypassing all your network firewall
protections (including the proxies own access controls), or causing your
cache to store infected malware and deliver it to every client on your
network (turning your proxy into a zombie infection source).


> Or, the only way is to revise the source code?

Please don't. The reasons behind this behaviour are very important to
protect against.

If you do, then you also need to ensure that the traffic through the
altered proxy is never cached. By your proxy or by anyone receiving its
responses.

You would do better investigating what ports (if any) QQ tries to use
for its own custom protocol and letting those through the firewall. Or
tryig to find and fix the source of the original broken HTTP message.

Amos