[squid-users] Squid intermittently not sending host header to peer

[Amos Jeffries]

On 4/09/18 2:13 AM, Michael Thomas wrote:
> HI Amos,
> 
> Thank you for responding.
> 
> To clarify, when I referred to HTTPS requests, I was referring to
> CONNECT requests - I should have been more clear, my apologies. No
> authentication is being performed by either server, so I'm not sure what
> you're seeing in the logs that relates to that.

The log format looks like Squid native format. On all the 200 status
transactions there is "connect" instead of "-" where that format prints
username.


> 
> CONNECT requests are logged correctly on both squid servers and appear
> to operate correctly for every request.
> 
> Interestingly, I was mistaken before. It's not the host header that's
> missing - that's still present. It's the full URI within the GET request.
> 

Nod. Squid2 is receiving an origin-form request. Such as a client would
send *inside* a CONNECT tunnel, or Squid would send on DIRECT traffic.

The former was what I suspected at first, but the message does say Via:
with Squid1 details. So somehow Squid1 must think this connection is a
DIRECT (origin) connection.


> As requested, here is all the information:
> 
> *Squid1 version and build information:*
> Squid Cache: Version 3.5.12
> Service Name: squid
> Ubuntu linux

Please upgrade his machine if you can. All this may turn out to be a
side effect of one of the many bugs fixed already.


> 
> Here is a verbatim copy of both squid.conf files, with sensitive
> information replaced:
> 
> *Squid1:*
> http_port 3128 name=port_3128
> http_access allow all
> nonhierarchical_direct off
> 
> acl port_3128_acl myportname port_3128
> always_direct deny port_3128_acl
> never_direct allow port_3128_acl

If this is our actual config there is no need for these ACLs. This Squid
already accepts *everything* it is handed which has even vague
resemblance of HTTP syntax. All they are doing is making a false
illusion of some control existing.

It should be sufficient to use:
  never_direct allow all
  cache_peer_access proxy3128 allow all


Really you should leave the security checks we put into the default
config. They are there to prevent things like Squid being instructed to
send spam email, or worse DoS'ing your internal network.


> 
> # 3128
> cache_peer 2.2.2.2 parent 3128 0 no-query proxy-only default  name=proxy3128
> cache_peer_access proxy3128 allow port_3128_acl
> cache_peer_access proxy3128 deny all
> debug_options 11,2
> 
> 
> *Squid2:*
> http_access allow all
> http_port 3128
> debug_options 11,2
> 
> 
> And here is a copy of the cache.log for a failed request:
> 
> *Squid1:*
...
> ----------
> 2018/09/03 13:36:45.088 kid1| 11,2| http.cc(2234) sendRequest: HTTP
> Server local=1.1.1.1:55718 <http://1.1.1.1:55718/> remote=2.2.2.2:3128
> <http://2.2.2.2:3128/> FD 14 flags=1
> 2018/09/03 13:36:45.089 kid1| 11,2| http.cc(2235) sendRequest: HTTP
> Server REQUEST:
> ---------
> GET /messages/391/ HTTP/1.1
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> Accept-Encoding: gzip, deflate
> Accept-Language: en-US,en;q=0.9,en-GB;q=0.8
> Cookie: __cfduid=redacted; csrftoken=redacted; sessionid=redacted;
> _ga=redacted
> AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0.3
> Host: redacted.com <http://redacted.com/>
> Via: 1.1 Squid1 (squid/3.5.12)
> X-Forwarded-For: 3.3.3.3
> Cache-Control: max-age=0
> Connection: keep-alive
> 


Okay. Next thing to do is identify what Squid1 thinks type of connection
this FD is used for. Please add debug level "44,3 51,3" to the Squid1
config and repeat the test.



Amos