[squid-users] Chrome 69

[neok]

Hello everyone!
I'm a bit lost with the behavior of Google Chrome 69.0 for Win 64 and my
squid rules 3.5.20.
Until a few days ago when browsing denied sites Chrome threw the error
"ERR_TUNNEL_CONNECTION_FAILED" which was fine for me.
Firefox 62 threw the error "The proxy server is refusing connections" which
was also fine for me.
Now Chrome shows me the login window every time I visit a denied site.
I suspect Chrome has been updated and changed its behavior. I'm currently
studying that possibility.
I'm also rethinking whether the way I'm denying sites is the right one.
I leave my settings so that someone with more experience can give me some
feedback.
I am very grateful for any indication.
Best regards,
Gabriel.


squid.conf
### Negotiate/NTLM and Negotiate/Kerberos authentication
auth_param negotiate program /usr/sbin/negotiate_wrapper --ntlm
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --kerberos
/usr/lib64/squid/negotiate_kerberos_auth -r -i -s GSS_C_NO_NAME
auth_param negotiate children 200
auth_param negotiate keep_alive on

### standard allowed ports
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

### destination domains to be blocked in a HTTP access control policy
acl LS_adult dstdomain -i "/etc/squid/DBL/adult.txt"
acl LS_anonvpn dstdomain -i "/etc/squid/DBL/anonvpn.txt"
acl LS_hacking dstdomain -i "/etc/squid/DBL/hacking.txt"
acl LS_malicius dstdomain -i "/etc/squid/DBL/malicius.txt"
acl LS_remotecontrol dstdomain -i "/etc/squid/DBL/remotecontrol.txt"
acl LS_warez dstdomain -i "/etc/squid/DBL/warez.txt"
acl LS_youtube dstdomain -i "/etc/squid/DBL/youtube.txt"

### acl for proxy authentication (kerberos or ntlm)
acl auth proxy_auth REQUIRED

### LDAP group membership sources ###
external_acl_type AD_WEB_ACCESS %LOGIN /usr/lib64/squid/ext_ldap_group_acl
-P -R -b "OU=NETGOL,DC=netgol,DC=local" -D ldap -W
"/etc/squid/ldap_pass.txt" -f
"(&(sAMAccountname=%u)(memberof=cn=%g,OU=INTERNET,OU=PERMISOS,OU=NETGOL,DC=netgol,DC=local))"
-h s-dc1.netgol.local
acl WEB_ACCESS_1 external AD_WEB_ACCESS WEB_ACCESS_1
acl WEB_ACCESS_2 external AD_WEB_ACCESS WEB_ACCESS_2
acl WEB_ACCESS_3 external AD_WEB_ACCESS WEB_ACCESS_3
acl WEB_ACCESS_YT_ONLY external AD_WEB_ACCESS WEB_ACCESS_YT_ONLY

### HTTP access control policies
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access deny !auth
http_access allow localhost
http_access deny LS_malicius # malicius sites denied for all

http_access allow WEB_ACCESS_1 # WEB_ACCESS_1 member users can browse
without restrictions

http_access deny WEB_ACCESS_2 LS_remotecontrol # WEB_ACCESS_2 member users
can't browse Remote Control sites
http_access deny WEB_ACCESS_2 LS_warez # WEB_ACCESS_2 member users can't
browse Warez sites
http_access allow WEB_ACCESS_2 # WEB_ACCESS_2 member users can browse the
rest of the sites not bloqued

http_access deny WEB_ACCESS_3 LS_adult # WEB_ACCESS_3 member users can't
browse Adult sites
http_access deny WEB_ACCESS_3 LS_anonvpn # WEB_ACCESS_3 member users can't
browse Anonymous VPN sites
http_access deny WEB_ACCESS_3 LS_hacking # WEB_ACCESS_3 member users can't
browse Hacking sites
http_access deny WEB_ACCESS_3 LS_remotecontrol # WEB_ACCESS_3 member users
can't browse Remote Control sites
http_access deny WEB_ACCESS_3 LS_warez # WEB_ACCESS_3 member users can't
browse Warez sites
http_access allow WEB_ACCESS_3 # WEB_ACCESS_3 member users can browse the
rest of the sites not bloqued

http_access allow WEB_ACCESS_YT_ONLY LS_youtube # WEB_ACCESS_YT_ONLY member
users can browse YouTube
http_access deny WEB_ACCESS_YT_ONLY # WEB_ACCESS_YT_ONLY member
users can't browse the rest of sites

http_access deny all

### PERSONALIZATION ###
http_port 8080
coredump_dir /var/spool/squid
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
quick_abort_min 0 KB
quick_abort_max 0 KB
read_timeout 5 minutes
request_timeout 3 minutes
shutdown_lifetime 15 seconds
ipcache_size 2048
fqdncache_size 4096
forwarded_for off
httpd_suppress_version_string on


Mi lab scenario:
- A VM CentOS 7 Core over VirtualBox 5.2, 1 NIC.
- My VM is attached to my domain W2012R2 (following this post
https://www.rootusers.com/how-to-join-centos-linux-to-an-active-directory-domain/)
to achieve kerberos authentication transparent to the user. SElinux
disabled. Owner permissions to user squid in all folders/files involved.
- squid 3.5.20



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html

[Antony Stone]

Post by neok
Hello everyone!
I'm a bit lost with the behavior of Google Chrome 69.0 for Win 64 and my
squid rules 3.5.20.
Until a few days ago

Any idea what changed a few days ago?

Post by neok
when browsing denied sites Chrome threw the error
"ERR_TUNNEL_CONNECTION_FAILED" which was fine for me.
Firefox 62 threw the error "The proxy server is refusing connections" which
was also fine for me.
Now Chrome shows me the login window every time I visit a denied site.

What does Firefox do?

Post by neok
I suspect Chrome has been updated and changed its behavior. I'm currently
studying that possibility.
I'm also rethinking whether the way I'm denying sites is the right one.
I leave my settings so that someone with more experience can give me some
feedback.

It would be useful if you showed us the Squid access log entries for a denied
site you try to visit, which produces the above browser responses.


Antony.

[neok]

As far as I know, nothing's changed. The only thing that could have happened
is that Chrome was updated. I'm reviewing that.

This say Firefox when try acces to denied site:
The proxy server is refusing connections.
Firefox is configured to use a proxy server that is refusing connections.


Try access denied site through Firefox:

1538425226.377 0 10.10.11.154 TCP_DENIED/407 4147 CONNECT
www.amazon.com:443 - HIER_NONE/- text/html
1538425226.387 0 10.10.11.154 TCP_DENIED/407 4199 CONNECT
safebrowsing.googleapis.com:443 - HIER_NONE/- text/html
1538425226.406 23 10.10.11.154 TCP_DENIED/407 6996 CONNECT
tiles.services.mozilla.com:443 my.name HIER_NONE/- text/html
1538425226.409 17 10.10.11.154 TCP_DENIED/407 6944 CONNECT
www.amazon.com:443 my.name HIER_NONE/- text/html
1538425226.414 18 10.10.11.154 TCP_DENIED/407 6990 CONNECT
safebrowsing.googleapis.com:443 my.name HIER_NONE/- text/html
1538425226.454 0 10.10.11.154 TCP_DENIED/407 4195 CONNECT
tiles.services.mozilla.com:443 - HIER_NONE/- text/html
1538425226.457 7 10.10.11.154 TCP_DENIED/407 6998 CONNECT
tiles.services.mozilla.com:443 my.name HIER_NONE/- text/html
1538425226.482 10 10.10.11.154 TCP_DENIED/407 6988 CONNECT
tiles.services.mozilla.com:443 my.name HIER_NONE/- text/html


Try access denied site through Chrome:
1538425414.983 0 10.10.11.154 TCP_DENIED/407 4156 CONNECT
www.amazon.com:443 - HIER_NONE/- text/html
1538425414.983 0 10.10.11.154 TCP_DENIED/407 4156 CONNECT
www.amazon.com:443 - HIER_NONE/- text/html
1538425415.013 26 10.10.11.154 TCP_DENIED/407 6947 CONNECT
www.amazon.com:443 my.name HIER_NONE/- text/html
1538425415.016 0 10.10.11.154 TCP_DENIED/407 4201 CONNECT
www.amazon.com:443 my.name HIER_NONE/- text/html
1538425429.157 0 10.10.11.154 TCP_DENIED/407 4168 CONNECT
www.google.com.ar:443 - HIER_NONE/- text/html
1538425429.232 0 10.10.11.154 TCP_DENIED/407 4156 CONNECT
www.amazon.com:443 - HIER_NONE/- text/html
1538425429.233 0 10.10.11.154 TCP_DENIED/407 4156 CONNECT
www.amazon.com:443 - HIER_NONE/- text/html
1538425429.284 46 10.10.11.154 TCP_DENIED/407 6957 CONNECT
www.amazon.com:443 my.name HIER_NONE/- text/html
1538425429.286 0 10.10.11.154 TCP_DENIED/407 4201 CONNECT
www.amazon.com:443 my.name HIER_NONE/- text/html

In this case the authentication pop-up appears. When I use Firefox it never
appears.

Really weird...




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html

[Amos Jeffries]

Post by neok
As far as I know, nothing's changed. The only thing that could have happened
is that Chrome was updated. I'm reviewing that.
The proxy server is refusing connections.
Firefox is configured to use a proxy server that is refusing connections.

As you an see from the access.log Squid is presenting 407 auth
challenged in response to these CONNECT requests.

It is welcome news to hear Chrome is finally been fixed to actually
perform authentication for CONNECT tunnels. While it may have been okay
with you the previous behaviour is actually a long-standing Browser bug
and violation of HTTP on their part.

Post by neok
Now Chrome shows me the login window every time I visit a denied site.
I suspect Chrome has been updated and changed its behavior. I'm currently
studying that possibility.
I'm also rethinking whether the way I'm denying sites is the right one.

...

Post by neok
http_access allow WEB_ACCESS_YT_ONLY LS_youtube
http_access deny WEB_ACCESS_YT_ONLY

The "deny WEB_ACCESS_YT_ONLY" line is triggering the re-authentication.

When the reason for denial is due to credentials (ie %LOGIN for the
external ACL evaluation) a 407 authentication challenge is produced.

Notice that in the config I helped you develop a few days ago all the
other uses of these external ACL tests for "deny" action are followed by
another ACL test that is unrelated to the auth process. Usually a regex
or dstdomain check. It is these other ACL checks which prevent any of
those lines triggering similar auth challenges as they deny traffic.


Since the next thing your config is doing is a "deny all" you can remove
this "deny WEB_ACCESS_YT_ONLY" line entirely and the popups should
disappear while still having that traffic denied.


If you have other config policies to be added later there are some other
things you can do. But those will depend on what the other policies are
going to require, so I wont cover it now. Just be aware you may have to
revisit that YT access rule when adding other policies.


Amos

[Service MV]

Excellent Amos!
I have to admit that I was approaching that conclusion. I did exactly as
you told me and problem solved.
I will consider your recommendations when I need to add more rules.
Best regards!

Gabriel

El lun., 1 de oct. de 2018 a la(s) 18:04, Amos Jeffries (

Post by neok

Post by neok
As far as I know, nothing's changed. The only thing that could have

happened

Post by neok
is that Chrome was updated. I'm reviewing that.
The proxy server is refusing connections.
Firefox is configured to use a proxy server that is refusing connections.

As you an see from the access.log Squid is presenting 407 auth
challenged in response to these CONNECT requests.
It is welcome news to hear Chrome is finally been fixed to actually
perform authentication for CONNECT tunnels. While it may have been okay
with you the previous behaviour is actually a long-standing Browser bug
and violation of HTTP on their part.

Post by neok
Now Chrome shows me the login window every time I visit a denied site.
I suspect Chrome has been updated and changed its behavior. I'm currently
studying that possibility.
I'm also rethinking whether the way I'm denying sites is the right one.

...

Post by neok
http_access allow WEB_ACCESS_YT_ONLY LS_youtube
http_access deny WEB_ACCESS_YT_ONLY

The "deny WEB_ACCESS_YT_ONLY" line is triggering the re-authentication.
When the reason for denial is due to credentials (ie %LOGIN for the
external ACL evaluation) a 407 authentication challenge is produced.
Notice that in the config I helped you develop a few days ago all the
other uses of these external ACL tests for "deny" action are followed by
another ACL test that is unrelated to the auth process. Usually a regex
or dstdomain check. It is these other ACL checks which prevent any of
those lines triggering similar auth challenges as they deny traffic.
Since the next thing your config is doing is a "deny all" you can remove
this "deny WEB_ACCESS_YT_ONLY" line entirely and the popups should
disappear while still having that traffic denied.
If you have other config policies to be added later there are some other
things you can do. But those will depend on what the other policies are
going to require, so I wont cover it now. Just be aware you may have to
revisit that YT access rule when adding other policies.
Amos
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users