[squid-users] squid 3.5.27 . https website

[Amos Jeffries]

On 17/11/17 15:32, G~D~Lunatic wrote:
> i use squid 3.5.27 as a transparent proxy.

Small correction: You have configured NAT interception proxy with 
SSL-Bump'ing. Not truly transparent.
  There are some vital differences. Most specific to your case is that 
interception proxies do alter the traffic in significant ways (not 
transparently relay as-is).


> With the proxy , i access 
> some https websites like www.hupu.com. But the 
> webpage does not show correctly.  There are some websizes similar such 
> as https://www.zhihu.com, https://www.jd.com/. So i want to know where problem is or how to 
> deal with it.
> 
> The webpage remind like"   s1.hdslb.com used an invalid security 
> certificate. This certificate is valid for the following domain names 
> only: * .zhaopin.com, * .zhaopin.cn, * .dpfile.com, * .cdn.myqcloud.com, 
> * .sogoucdn. SSL error code: SSL_ERROR_BAD_CERT_DOMAIN  "
> 
> how can i send a screenshot to explain?
> Here is my configure
> # Recommended minimum configuration:
> #
> 
> # 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.16.0.0/12  # 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 777         # multiling http
> acl CONNECT method CONNECT
> 
> #
> # Recommended minimum Access Permission configuration:
> #
> # 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
> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager
> http_access allow all

*Extremely* unsafe configuration. This proxy is now an "open proxy". 
Anybody can abuse it for any use whatsoever.

Combined with how you have disabled below recording of all TLS traffic 
problems (and thus hacking attempts) and do server-first bumping of 
clients what you end up with is a remarkably dangerous piece of software 
whose most useful property is being a way to attack your network. :-(



> 
> # 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
> 
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
> 
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
> http_access allow localnet
> http_access allow localhost
> acl NCACHE method GET
> no_cache deny NCACHE

"no_cache" is an deprecated directive. It was removed because it 
confused people. Delete the "no_" prefix.


Also, most other methods are not cacheable. So why not do it the simple way?

  cache deny all
or
  store_miss deny all


> 
> # And finally deny all other access to this proxy
> request_header_access Via deny all #hide squid header
> request_header_access X-Forwarded-For deny all #hide squid header
> #request_timeout 2 minutes #client request timeout
> 

The above is a very slow and nasty way to perform:

  via off
  forwarded_for delete


Though if you want to be transparent, use these instead:
  via off
  forwarded_for transparent


> # Squid normally listens to port 3128
> http_port 3120
> 
> http_port 3128 intercept
> 
> https_port 192.168.51.115:3129 intercept ssl-bump connection-auth=off 
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 
> cert=/usr/local/squid/ssl_cert/myCA.pem 
> key=/usr/local/squid/ssl_cert/myCA.pem
> always_direct allow all

The use of "always_direct allow all" is a now useless workaround for a 
long ago fixed bug. No version of Squid available in any distro today 
needs it.


> ssl_bump server-first all
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> ssl_bump peek ssl_step1
> ssl_bump splice all

You are mixing up rules from multiple different versions of the SSL-Bump 
feature.

"server-first" is equivalent to:

  ssl_bump peek ssl_step1
  ssl_bump bump all

It overrides all the ssl_bump lines following it.


> 
> sslproxy_version 0
> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER

Remove all three of the above lines. You may then be able to see what is 
going on if the errors are in the TLS layer.

All these lines do is hide errors and network abuse from *you*, the 
admin. Not your clients or users - they will still get errors.


I think your problem is that the bumping done by "server-first" is 
clashing with several modern TLS features that sites use. You will not 
be able to see which problem it is though until you re-enable recording 
and display of TLS issues.


Amos