Re: [squid-users] squid 3.1.10 https visit bug

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 04 Jun 2014 21:44:51 +1200

On 4/06/2014 5:01 p.m., anly.zhang wrote:
> Hi All:
> I want to install a getway server Between the company local area
> network (LAN) and internet;
> After the installation is complete,I found localnet client can visit http
> website but coudn't visit https website(e.g https://www.google.com)。thanks
> for any help!
>
>
> *squid.conf:*
> auth_param ntlm program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 20
> auth_param ntlm keep_alive on
> auth_param basic program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-basic
> auth_param basic children 20
> auth_param basic realm Squid proxy-caching web server
> auth_param basic credentialsttl 2 hours
> auth_param basic casesensitive off
> external_acl_type NT_global_group %LOGIN /usr/lib64/squid/wbinfo_group.pl
> #
> # Recommended minimum configuration:
> #
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
> # Example rule allowing access from your local networks.
> # Adapt to list your (internal) IP networks from where browsing
> # should be allowed
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> #acl localnet src 172.18.1.0/24 # RFC1918 possible internal network
> #acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> #acl localnet src fc00::/7 # RFC 4193 local private network range
> #acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged)
> machines
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 1433 # sxtc
> acl Safe_ports port 445 # sxtc
> acl Safe_ports port 139 # sxtc
> acl Safe_ports port 777 # multiling http
> acl whitelist dstdomain "/etc/squid/web"
> acl vip src "/etc/squid/vip"
> acl CONNECT method CONNECT
> acl ProxyUsers external NT_global_group "/etc/squid/net"
> acl white external NT_global_group "/etc/squid/white"
> acl AuthenticatedUsers proxy_auth REQUIRED

> http_access allow CONNECT

Meaning any software (LAN *or WAN*) which can reach your proxy is able
to do anything they like so long as they start the behaviour with an
HTTP CONNECT method...

> http_access allow Safe_ports
> http_access allow SSL_ports

... or are connecting to just about any IP:port.

Yes clients can reach any website. Are they even authenticating? Because
I very much doubt any traffic actually reaches the following http_access
rules.

> http_access allow AuthenticatedUsers ProxyUsers
> http_access allow AuthenticatedUsers white whitelist
> http_access allow vip
> #
> # Recommended minimum Access Permission configuration:
> #
> # Only allow cachemgr access from localhost
> http_access allow manager localhost
> http_access deny manager
> #http_access deny all

To fix your config:

step1) remove all the http_access lines above here. Don't worry we paste
them in again below.

> # Deny requests to certain unsafe ports
> #http_access deny !Safe_ports
> # Deny CONNECT to other than secure SSL ports
> #http_access deny CONNECT !SSL_ports

step 2) Uncomment the above settings.

> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> #http_access deny to_localhost
> visible_hostname zkbr-gw

step 3) check the DNS on this hostname.
  http://zkbr-gw/ does not resolve for me. Does it at least resolve in
your LAN ?

> dns_nameservers 10.1.1.3
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

Note that down here is where your custom security settings are supposed
to be.

step 3) paste your local config settings back in at this position (like
it says in BOLD).

 #
 # Recommended minimum Access Permission configuration:
 #
 # Only allow cachemgr access from localhost
 http_access allow manager localhost
 http_access deny manager

# NOTE: to restrict proxy config access you could change the above to:
# http_access deny manager !localhost

 http_access allow AuthenticatedUsers ProxyUsers
 http_access allow AuthenticatedUsers white whitelist
 http_access allow vip

step 4) at this point your config is back to a normal secure setup. The
problem may not be resolved, but we are at a safe place to start further
experiments which are outlined at the end of this mail.

> # And finally deny all other access to this proxy
> http_access deny all
> # Squid normally listens to port 3128
> http_port 3128
> # We recommend you to use at least the following line.
> hierarchy_stoplist cgi-bin ?

That recommendation has changed. The above "hierarchy_stoplist" can be
removed now.

> # Uncomment and adjust the following to add a disk cache directory.
> cache_dir ufs /var/spool/squid 10240 16 256
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
> # Add any of your own refresh_pattern entries above these.
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> access.log:
> 1401857885.705 61037 10.0.10.10 TCP_MISS/503 0 CONNECT www.google.com:443 -
> DIRECT/173.194.127.179 -
> 1401857907.994 238 10.0.10.10 TCP_MISS/000 0 GET
> http://api.bing.com/qsml.aspx? - DIRECT/23.15.14.35 -
> 1401857908.346 318 10.0.10.10 TCP_MISS/200 942 GET
> http://api.bing.com/qsml.aspx? - DIRECT/23.15.14.35 text/xml
> 1401857909.180 257 10.0.10.10 TCP_MISS/200 943 GET
> http://api.bing.com/qsml.aspx? - DIRECT/23.15.14.35 text/xml
> 1401857909.502 244 10.0.10.10 TCP_MISS/200 976 GET
> http://api.bing.com/qsml.aspx? - DIRECT/23.15.14.35 text/xml
> 1401857910.111 246 10.0.10.10 TCP_MISS/200 978 GET
> http://api.bing.com/qsml.aspx? - DIRECT/23.15.14.35 text/xml
> 1401857911.438 273 10.0.10.10 TCP_MISS/000 0 GET
> http://api.bing.com/qsml.aspx? - DIRECT/23.15.14.35 -
> 1401857915.728 61648 10.0.10.10 TCP_MISS/503 0 CONNECT www.google.com:443 -
> DIRECT/173.194.127.179 -
> 1401857974.780 61693 10.0.10.10 TCP_MISS/503 0 CONNECT mail.abc.cc:443 -
> DIRECT/x.x.x.x -
>

As I suspected. No sign of any login.

Those 503 messages are a sign of TCP connections to the remove servers
failing to be setup. This is specifically the SYN and SYN-ACK packets of
TCP having issues.

 * check that port 443 access is permitted (at least to Squid) through
the network firewall.

 * check the contents of the 503 error page sent back to clients. This
may or may not be easy to find in the browser. Try enabling the browsers
developer tools "Network" panel and refreshing the https:// page and see
if its visible in there. Worst case a tcpdump of packet bodies might
have to be examined.

Those status 000 lines are a sign that requests are leaving Squid to
upstream servers but no response is arriving back. Could be other TCP
issues ( or broken ECN or Window scaling)

 * check for PMTUd issues caused by blocking ICMP.
 * check for ECN or Window scaling issues.

Amos
Received on Wed Jun 04 2014 - 09:45:05 MDT

This archive was generated by hypermail 2.2.0 : Thu Jun 05 2014 - 12:00:05 MDT