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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
