<html>
<head>
<meta http-equiv="content-type" content: text/html; charset=utf-8>
</head>
<body>
Thank you for all your suggestions Mister.<br>
<br>
I improved my conf by them and disabled squidguard for testing and its
working now fine without squidguard.<br>
So I need to investigate why squidguard won't run with https sites on v
3.5.25<br>
<br>
squidGuard -v<br>
SquidGuard: 1.5 Berkeley DB 5.3.28: (September 9, 2013)<br>
<br>
How can I find out what happens between Squid, SquidGuard at debian and
Firefox at client side ?<br>
<br>
I tried echo tests locally with squidguard but it only shows ERR results
with https sites.<br>
Http sites are working well as expected with squidguard<br>
<br>
Here my new squid.conf<br>
<br>
<span style="color: gray;">05/29/17 00:03:49, Amos Jeffries <<a
href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>>:</span><br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">On 29/05/17 07:52, Andi wrote:<br>
> Hi<br>
><br>
> I installed Squid 3.5.25 at debian with libecap3 too.<br>
><br>
> Now my old squid.conf file for v3.48 not work anymore for<br>
> redirected https websites.<br>
> I get SSL_ERROR_RX_RECORD_TOO_LONG in Firefox.<br>
> I redirected them before by Shorewall and it worked with v3.48<br>
> #SQUID-PORTS<br>
> REDIRECT loc 3140 tcp https - !192.168.1.254<br>
> REDIRECT loc 3139 tcp www - !192.168.1.254<br>
><br>
><br>
> If I change https_port to http_port and remove the intercept<br>
> option for ssl_bump it works with expicit configured clients
for<br>
> that port even for gmail website too.<br>
> What I need to change to make squid 3.5 work transparently ?<br>
><br>
<br>
SSL_ERROR_RX_RECORD_TOO_LONG is apparently what gets displayed if the <br>
response coming back from an attempted TLS/SSL connection is not TLS/SSL
<br>
protocol. Such as Squid responding with an HTTP error message, or <br>
something like that happening.<br>
<br>
<br>
Your below config has port 3128 for explicit-proxy traffic, port 3139 <br>
for intercepted port 80 traffic, and 3140 for intercepted port 443
traffic.<br>
<br>
Your log startup confirms that:<br>
<br>
> 2017/05/28 16:07:55.701| Accepting HTTP Socket connections at <br>
local=0.0.0.0:3138 remote=[::] FD 28 flags=9<br>
> 2017/05/28 16:07:55.702| Accepting NAT intercepted HTTP Socket <br>
connections at local=0.0.0.0:3139 remote=[::] FD 29 flags=41<br>
> 2017/05/28 16:07:55.702| Accepting NAT intercepted SSL bumped HTTPS
<br>
Socket connections at local=0.0.0.0:3140 remote=[::] FD 30 flags=41<br>
<br>
<br>
The first thing I would check is that the shorewall definitions of <br>
"https" and "www" are actually 80 and 443 respectively.<br>
<br>
Then try to find out what Squid is sending to Firefox that would result
<br>
in that particular error. I suspect either ICAP or SquidGuard is trying
<br>
to change or produce a plan-text response to the initial CONNECT <br>
messages Squid uses internally for the SSL-Bump steps.<br>
<br>
<br>
<br>
NP: the "abandoning" messages in cache.log are nothing to worry about <br>
when you are ssl-bump'ing with Squid-3, it is just an annoying <br>
side-effect of how SSL-Bump takes the connection away from the normal <br>
CONNECT tunnel handling code. IIRC it has been fixed in Squid-4 along <br>
with a lot of similar little PITA things.<br>
<br>
PS. I've highlighted some improvements you can make to the config below.
<br>
They are not related to your problem though.<br>
<br>
> squid -v<br>
> Squid Cache: Version 3.5.25<br>
> Service Name: squid<br>
> configure options: '--build=x86_64-linux-gnu' '--prefix=/usr'<br>
> '--localstatedir=/var/squid' '--libexecdir=/lib/squid'<br>
> '--srcdir=.' '--datadir=/share/squid'
'--sysconfdir=/etc/squid'<br>
> '--disable-ipv6' '--with-default-user=proxy'<br>
> '--with-logdir=/var/log/squid35'<br>
> '--with-pidfile=/var/run/squid35.pid' '--with-openssl'<br>
> '--enable-ssl-crtd' '--infodir=/share/info'<br>
> '--includedir=/include' '--mandir=/usr/share/man'<br>
> '--enable-inline' '--disable-arch-native'<br>
> '--disable-maintainer-mode' '--disable-dependency-tracking'<br>
> '--disable-silent-rules' '--enable-async-io=8'<br>
> '--enable-storeio=ufs,aufs,diskd,rock'<br>
> '--enable-removal-policies=lru,heap' '--enable-delay-pools'<br>
> '--enable-cache-digests' '--enable-icap-client'<br>
> '--enable-follow-x-forwarded-for'<br>
>
'--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB'<br>
> '--enable-auth-digest=file,LDAP'<br>
> '--enable-auth-negotiate=kerberos,wrapper'<br>
> '--enable-auth-ntlm=fake,smb_lm'<br>
>
'--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group'<br>
> '--enable-url-rewrite-helpers=fake' '--enable-eui'
'--enable-esi'<br>
> '--enable-icmp' '--enable-zph-qos' '--enable-ecap'<br>
> '--disable-translation' '--with-filedescriptors=65536'<br>
> '--with-large-files' '--enable-linux-netfilter' 'CFLAGS=-g -O2<br>
> -fPIE -fstack-protector-strong -Wformat
-Werror=format-security<br>
> -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now'<br>
> 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE<br>
> -fstack-protector-strong -Wformat -Werror=format-security'<br>
> 'build_alias=x86_64-linux-gnu'<br>
><br>
> cat /etc/squid/squid.conf:<br>
> debug_options ALL,6<br>
> #0 26,2 83,2 33,2 17,2 44,2<br>
> logformat datetime %tl %6tr CLIENT:%>a = = %Ss %<Hs
%rm=%>ru<br>
> --%[un %Sh/%<a %mt<br>
> access_log /var/log/squid35/access.log datetime<br>
> forwarded_for on<br>
> error_directory /usr/share/squid/errors/de-de/<br>
><br>
<br>
Have you altered or otherwise touched the files in that directory?<br>
If not I suggest using this instead:<br>
<br>
error_default_language de-de<br>
<<a
href="http://master.squid-cache.org/Doc/config/error_default_language/">http://master.squid-cache.org/Doc/config/error_default_language/</a>><br>
<br>
> acl localnet src 192.168.1.0/24<br>
> acl SSL_ports port 443<br>
> acl Safe_ports port 80 # http<br>
> acl Safe_ports port 21 # ftp<br>
> acl Safe_ports port 443 # https<br>
> acl Safe_ports port 70 # gopher<br>
> acl Safe_ports port 210 # wais<br>
> acl Safe_ports port 1025-65535 # unregistered ports<br>
> acl Safe_ports port 280 # http-mgmt<br>
> acl Safe_ports port 488 # gss-http<br>
> acl Safe_ports port 591 # filemaker<br>
> acl Safe_ports port 777 # multiling http<br>
> acl CONNECT method CONNECT<br>
> http_access deny !Safe_ports<br>
> http_access deny CONNECT !SSL_ports<br>
> http_access allow localhost manager<br>
> http_access deny manager<br>
> http_access deny to_localhost<br>
> http_access allow localnet<br>
> http_access allow localhost<br>
> http_reply_access allow all<br>
><br>
<br>
No need to explicitly "allow all" for replies. That happens anyway. That
<br>
directive is mostly useful to deny things.<br>
<br>
<br>
> http_access deny all<br>
> icp_access allow localnet<br>
> icp_access deny all<br>
> ### NEW for v3.5x SSL-Bump ###<br>
> always_direct allow all<br>
><br>
<br>
That "always_direct" was a hack to workaround a bug in the first <br>
ssl-bump code. It is long since irrelevant. I recommend removing it.<br>
<br>
> acl step1 at_step SslBump1<br>
> acl step2 at_step SslBump2<br>
> acl step3 at_step SslBump3<br>
> ssl_bump splice localhost<br>
> #acl exclude_sites ssl::server_name_regex -i<br>
>
"/var/lib/squidguard/db/BL/whitelist-ssl/whitelist.destdomainlist"<br>
> ssl_bump peek step1 all<br>
> #ssl_bump splice exclude_sites<br>
> ssl_bump stare step2 all<br>
><br>
<br>
You don't need the "all" on the above lines. The "step2 all" is both <br>
unnecessary and adds confusion since that line does *not* apply to all <br>
step2 traffic - some was spliced instead by the previous line.<br>
<br>
> ssl_bump bump all<br>
> #############################<br>
> http_port 0.0.0.0:3138<br>
> http_port 0.0.0.0:3139 intercept<br>
> sslproxy_cert_adapt setCommonName ssl::certDomainMismatch<br>
> https_port 0.0.0.0:3140 intercept ssl-bump<br>
> generate-host-certificates=on dynamic_cert_mem_cache_size=16MB<br>
> cert=/etc/squid/myca.pem<br>
> sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE<br>
> sslproxy_capath /etc/ssl/certs<br>
> ##sslproxy_cafile /etc/ssl/certs/ca-certificates.crt<br>
> sslcrtd_program /bin/ssl_crtd -s /var/spool/squid_ssldb -M
16MB<br>
> sslcrtd_children 10<br>
> cache_dir ufs /etc/squid/ssl_db 100 16 256<br>
><br>
<br>
Why are you storing all cacheable *HTTP* objects into /etc/squid/ssl_db
?<br>
especially since your SSL certificate store is /var/spool/squid_ssldb
?<br>
<br>
> cache_mgr admin@mainrouter<br>
> visible_hostname xxx<br>
> httpd_suppress_version_string on<br>
> coredump_dir /var/spool/squid<br>
> refresh_pattern ^ftp: 1440 20% 10080<br>
> refresh_pattern ^gopher: 1440 0% 1440<br>
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br>
> refresh_pattern 0 20% 4320<br>
> cache_effective_user proxy<br>
><br>
<br>
You built this proxy with --with-default-user=proxy , which sets the <br>
default value of cache_effective_user to "proxy", no need to repeat that
<br>
in squid.conf.<br>
<br>
> icap_enable on<br>
> icap_send_client_ip on<br>
> icap_send_client_username on<br>
> icap_client_username_encode off<br>
> icap_client_username_header X-Authenticated-User<br>
> icap_preview_enable on<br>
> icap_preview_size 1024<br>
> icap_service service_req reqmod_precache bypass=0<br>
> icap://127.0.0.1:1344/squidclamav<br>
> icap_service service_resp respmod_precache bypass=0<br>
> icap://127.0.0.1:1344/squidclamav<br>
> adaptation_access service_req allow all<br>
> adaptation_access service_resp allow all<br>
> redirect_program /usr/bin/squidGuard -c<br>
> /etc/squidguard/squidGuard.conf<br>
> cache_effective_group proxy<br>
><br>
<br>
There should be no need for that cache_effective_group directive to be <br>
used. Simply check and limit the groups the cache_effective_user account
<br>
is a member of.<br>
<br>
> dns_nameservers 8.8.8.8<br>
><br>
<br>
Using that DNS service directly in Squid is particularly nasty. Each DNS
<br>
query usually hits a different server in their farm and thus gets <br>
different set of response IP addresses. I strongly recommend that you <br>
setup some local DNS recursive resolver that both the clients and Squid
<br>
can use. That resolver can of course pass its traffic to 8.8.8.8 if you
<br>
actually need to.<br>
<br>
<br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
squid-users@lists.squid-cache.org<br>
<a
href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote>
</body>
</html>