Re: [squid-users] How to intercept ssl_bump transparent NAT https websites

[Amos Jeffries]

On 29/05/17 07:52, Andi wrote:

Hi

I installed Squid 3.5.25 at debian with libecap3 too.

Now my old squid.conf file for v3.48 not work anymore for
redirected https websites.
I get SSL_ERROR_RX_RECORD_TOO_LONG in Firefox.
I redirected them before by Shorewall and it worked with v3.48
#SQUID-PORTS
REDIRECTloc3140 tcphttps- !192.168.1.254
REDIRECTloc3139 tcpwww- !192.168.1.254


If I change https_port to http_port and remove the intercept
option for ssl_bump it works with expicit configured clients for
that port even for gmail website too.
What I need to change to make squid 3.5 work transparently  ?



SSL_ERROR_RX_RECORD_TOO_LONG is apparently what gets displayed if the 
response coming back from an attempted TLS/SSL connection is not TLS/SSL 
protocol. Such as Squid responding with an HTTP error message, or 
something like that happening.



Your below config has port 3128 for explicit-proxy traffic, port 3139 
for intercepted port 80 traffic, and 3140 for intercepted port 443 traffic.


Your log startup confirms that:

> 2017/05/28 16:07:55.701| Accepting HTTP Socket connections at 
local=0.0.0.0:3138 remote=[::] FD 28 flags=9
> 2017/05/28 16:07:55.702| Accepting NAT intercepted HTTP Socket 
connections at local=0.0.0.0:3139 remote=[::] FD 29 flags=41
> 2017/05/28 16:07:55.702| Accepting NAT intercepted SSL bumped HTTPS 
Socket connections at local=0.0.0.0:3140 remote=[::] FD 30 flags=41



The first thing I would check is that the shorewall definitions of 
"https" and "www" are actually 80 and 443 respectively.


Then try to find out what Squid is sending to Firefox that would result 
in that particular error. I suspect either ICAP or SquidGuard is trying 
to change or produce a plan-text response to the initial CONNECT 
messages Squid uses internally for the SSL-Bump steps.




NP: the "abandoning" messages in cache.log are nothing to worry about 
when you are ssl-bump'ing with Squid-3, it is just an annoying 
side-effect of how SSL-Bump takes the connection away from the normal 
CONNECT tunnel handling code. IIRC it has been fixed in Squid-4 along 
with a lot of similar little PITA things.


PS. I've highlighted some improvements you can make to the config below. 
They are not related to your problem though.



squid -v
Squid Cache: Version 3.5.25
Service Name: squid
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr'
'--localstatedir=/var/squid' '--libexecdir=/lib/squid'
'--srcdir=.' '--datadir=/share/squid' '--sysconfdir=/etc/squid'
'--disable-ipv6' '--with-default-user=proxy'
'--with-logdir=/var/log/squid35'
'--with-pidfile=/var/run/squid35.pid' '--with-openssl'
'--enable-ssl-crtd' '--infodir=/share/info'
'--includedir=/include' '--mandir=/usr/share/man'
'--enable-inline' '--disable-arch-native'
'--disable-maintainer-mode' '--disable-dependency-tracking'
'--disable-silent-rules' '--enable-async-io=8'
'--enable-storeio=ufs,aufs,diskd,rock'
'--enable-removal-policies=lru,heap' '--enable-delay-pools'
'--enable-cache-digests' '--enable-icap-client'
'--enable-follow-x-forwarded-for'

'--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB'
'--enable-auth-digest=file,LDAP'
'--enable-auth-negotiate=kerberos,wrapper'
'--enable-auth-ntlm=fake,smb_lm'

'--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group'
'--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi'
'--enable-icmp' '--enable-zph-qos' '--enable-ecap'
'--disable-translation' '--with-filedescriptors=65536'
'--with-large-files' '--enable-linux-netfilter' 'CFLAGS=-g -O2
-fPIE -fstack-protector-strong -Wformat -Werror=format-security
-Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now'
'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE
-fstack-protector-strong -Wformat -Werror=format-security'
'build_alias=x86_64-linux-gnu'

cat /etc/squid/squid.conf:
debug_options ALL,6
#0 26,2 83,2 33,2 17,2 44,2
logformat datetime  %tl %6tr CLIENT:%>a = = %Ss %ru
--%[un %Sh/%

Have you altered or otherwise touched the files in that directory?
If not I suggest using this instead:

  error_default_language de-de



acl localnet src 192.168.1.0/24
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
   

Re: [squid-users] External ACL

[avi_h]

Hi Amos,

So I tried working with some older versions of squid but i still got the
same issue.
This happens both with my basic helper in python and with the
ext_sql_session_acl.
I'm kinda lost. Any chance you have any advice? Is it possible that the
issue is with the channel parameter?

Thanks,
Avi



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/External-ACL-tp4682519p4682616.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Yuri]

Yup, thank you, Amos, for details. I do not remember all changelogs exactly.


29.05.2017 3:09, Amos Jeffries пишет:
> On 29/05/17 05:21, Yuri wrote:
>>
>> 28.05.2017 21:09, Eduardo Carneiro пишет:
>>> Ok. Tell me what technical details you need and I post here.
>> Configs. Logs. Topology. Usecases. Examples for single transactions.
>>> But if this were an ignoring cache-control issue, wouldn't that
>>> happen on
>>> squid 3.5.19 and previous versions as well?
>>>
>>> With the same conf works on 3.5.19 but not in newest squid3 versions.
>> Once more. Ignoring cache-control in squid is deprecated due to RFC
>> requirements. So, it leads to drops down with byte HIT in general. I do
>> not remember when it exactly desupported in squid's code, but seems
>> approx. at some 3.5.x.
>
> From 3.5.19 onwards ..
>
> 3.5.21 added support for Squid to differentiate between revalidation
> checks that were always vs sometimes necessary. Fixing the situation
> where responses had both a CC:private or CC:no-cache header and
> information stating cacheability "freshness".
>
> 3.5.22 fixed issues that were then seen with missing Last-Modified and
> old Date values, and the Collapsed Forwarding feature.
>
> 3.5.23 added support for caching objects with "Vary: *" which depended
> on the change in .21, and caching of 3034 responses. Also fixed the
> main outstanding issue behind Host verify MISS happening, and a
> regression in the .22 collapsed forwarding change.
>
> 3.5.24 fixed a regression in the "cache deny" access control handling
> which was causing some thing to be cached and revalidated when they
> should not have. This may make some things now un-cacheable if there
> is a misconfiguration in that directive.
>
> 3.5.25 fixed a stall that happens when SSL-Bump interacts with Host
> verification through the SNI value. While not strictly related, having
> it fixed allows a lot more Google/YouTube/Akamai transactions to reach
> the caching stages so their operations start to be visible instead of
> splice/tunnel'ed.
>
>
> The expected effect of these changes was to fix several major
> unnecessary bandwidth uses;
>  - cached YouTube videos starting mid-video when someone else using
> the proxy had only partially watched the same video - causing the user
> to force-refresh and purge the cached video.
>  - Chrome and similar Google originated downloads being a MISS for
> identical objects.
>  - the often cited terrible HIT reduction on some major hosting
> services (again Google, though also Akamai) traffic since 3.2 Host
> verify was added.
>  - collapsed forwarding resulting in large objects being stored to the
> cache then immediately deleted by a parallel fetch.
>
>
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users




signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Amos Jeffries]

On 29/05/17 05:21, Yuri wrote:


28.05.2017 21:09, Eduardo Carneiro пишет:

Ok. Tell me what technical details you need and I post here.

Configs. Logs. Topology. Usecases. Examples for single transactions.

But if this were an ignoring cache-control issue, wouldn't that happen on
squid 3.5.19 and previous versions as well?

With the same conf works on 3.5.19 but not in newest squid3 versions.

Once more. Ignoring cache-control in squid is deprecated due to RFC
requirements. So, it leads to drops down with byte HIT in general. I do
not remember when it exactly desupported in squid's code, but seems
approx. at some 3.5.x.


From 3.5.19 onwards ..

3.5.21 added support for Squid to differentiate between revalidation 
checks that were always vs sometimes necessary. Fixing the situation 
where responses had both a CC:private or CC:no-cache header and 
information stating cacheability "freshness".


3.5.22 fixed issues that were then seen with missing Last-Modified and 
old Date values, and the Collapsed Forwarding feature.


3.5.23 added support for caching objects with "Vary: *" which depended 
on the change in .21, and caching of 3034 responses. Also fixed the main 
outstanding issue behind Host verify MISS happening, and a regression in 
the .22 collapsed forwarding change.


3.5.24 fixed a regression in the "cache deny" access control handling 
which was causing some thing to be cached and revalidated when they 
should not have. This may make some things now un-cacheable if there is 
a misconfiguration in that directive.


3.5.25 fixed a stall that happens when SSL-Bump interacts with Host 
verification through the SNI value. While not strictly related, having 
it fixed allows a lot more Google/YouTube/Akamai transactions to reach 
the caching stages so their operations start to be visible instead of 
splice/tunnel'ed.



The expected effect of these changes was to fix several major 
unnecessary bandwidth uses;
 - cached YouTube videos starting mid-video when someone else using the 
proxy had only partially watched the same video - causing the user to 
force-refresh and purge the cached video.
 - Chrome and similar Google originated downloads being a MISS for 
identical objects.
 - the often cited terrible HIT reduction on some major hosting 
services (again Google, though also Akamai) traffic since 3.2 Host 
verify was added.
 - collapsed forwarding resulting in large objects being stored to the 
cache then immediately deleted by a parallel fetch.



Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] How to intercept ssl_bump transparent NAT https websites

[Andi]

   

Hi
I installed Squid 3.5.25 at debian with
libecap3 too.

Now my old squid.conf file for v3.48 not work anymore for redirected https
websites.
I get SSL_ERROR_RX_RECORD_TOO_LONG in Firefox. 
I redirected them before by Shorewall and it worked with v3.48
#SQUID-PORTS
REDIRECT    loc    3140   
tcp    https    -   
!192.168.1.254
REDIRECT    loc    3139   
tcp    www    -   
!192.168.1.254


If I change https_port to http_port and remove the intercept option for
ssl_bump it works with expicit configured clients for that port even for
gmail website too.
What I need to change to make squid 3.5 work transparently  ?

squid -v
Squid Cache: Version 3.5.25
Service Name: squid
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr'
'--localstatedir=/var/squid' '--libexecdir=/lib/squid' '--srcdir=.'
'--datadir=/share/squid' '--sysconfdir=/etc/squid' '--disable-ipv6'
'--with-default-user=proxy' '--with-logdir=/var/log/squid35'
'--with-pidfile=/var/run/squid35.pid' '--with-openssl' '--enable-ssl-crtd'
'--infodir=/share/info' '--includedir=/include' '--mandir=/usr/share/man'
'--enable-inline' '--disable-arch-native' '--disable-maintainer-mode'
'--disable-dependency-tracking' '--disable-silent-rules'
'--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock'
'--enable-removal-policies=lru,heap' '--enable-delay-pools'
'--enable-cache-digests' '--enable-icap-client'
'--enable-follow-x-forwarded-for'
'--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-filedescriptors=65536' '--with-large-files' '--enable-linux-netfilter' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security' 'build_alias=x86_64-linux-gnu'

cat /etc/squid/squid.conf:
debug_options ALL,6
#0 26,2 83,2 33,2 17,2 44,2
logformat datetime  %tl %6tr CLIENT:%>a = = %Ss %ru
--%[un %Sh/%
access_log  /var/log/squid35/access.log datetime
forwarded_for on
error_directory /usr/share/squid/errors/de-de/
acl localnet src 192.168.1.0/24
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
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access deny to_localhost
http_access allow localnet
http_access allow localhost
http_reply_access allow all
http_access deny all
icp_access allow localnet
icp_access deny all
### NEW for v3.5x SSL-Bump ###
always_direct allow all
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump splice localhost
#acl exclude_sites ssl::server_name_regex -i
"/var/lib/squidguard/db/BL/whitelist-ssl/whitelist.destdomainlist"
ssl_bump peek step1 all
#ssl_bump splice exclude_sites
ssl_bump stare step2 all
ssl_bump bump all 
#
http_port 0.0.0.0:3138
http_port 0.0.0.0:3139 intercept
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch
https_port 0.0.0.0:3140 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=16MB cert=/etc/squid/myca.pem
sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
sslproxy_capath /etc/ssl/certs
##sslproxy_cafile /etc/ssl/certs/ca-certificates.crt
sslcrtd_program /bin/ssl_crtd -s /var/spool/squid_ssldb -M 16MB
sslcrtd_children 10
cache_dir ufs /etc/squid/ssl_db 100 16 256
cache_mgr admin@mainrouter
visible_hostname xxx
httpd_suppress_version_string on 
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
cache_effective_user proxy
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_preview_enable on
icap_preview_size 1024
icap_service service_req reqmod_precache bypass=0
icap://127.0.0.1:1344/squidclamav
icap_service service_resp respmod_precache bypass=0
icap://127.0.0.1:1344/squidclamav
adaptation_access service_req allow all
adaptation_access service_resp allow all

Re: [squid-users] Squid TPROXY issues with Google sites

[Alex Rousskov]

On 05/28/2017 05:40 AM, Vieri wrote:

> Please keep in mind that I'm basically an end-user, a sys-admin. I
> wish I had the time to study Squid's source code.

Nobody (certainly not me) has suggested anything that requires studying
Squid source code. If you think that I have, you have misinterpreted
what I have said.


> The cache log reports errors but they are not necessarily related to
> this client as there are many others actively browsing.

I recommend triaging this using a Squid instance isolated from all other
traffic. You are making both your job and the job of those who are
trying to help you more difficult by trying to save a few minutes/hours
that are usually required to set up an isolated test.


> Anyway, as a workaround I'm willing to splice/tunnel traffic to
> accounts.google.com *ONLY*, and bump everything else (although I'd
> prefer to understand why bumping isn't "working" for this site).

> I've tried this:

> acl GoogleAccounts ssl::server_name accounts.google.com
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump splice GoogleAccounts
> ssl_bump bump all

> However, traffic to accounts.google.com is not spliced, it's bumped
> like the rest.

You need to figure out why. Two common reasons are SSL-level errors and
http_access denials. Both should be reflected in access.log and
debugging cache.log.


> Can FQDNs be used in ACLs as in the example above even when peeking at step 1?

Yes. They may not work, but they can be used. They should work if the
request contains TLS SNI. Modern browser requests usually do, but you
can confirm by studying browser-Squid traffic with a tool like Wireshark.


> If I peek at step 2 then I won't be able to "bump all"

Correct.


> Likewise, If I need to stare at step 2 then I'll never be able to splice

Correct.


Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Yuri]

28.05.2017 21:09, Eduardo Carneiro пишет:
> Ok. Tell me what technical details you need and I post here.
Configs. Logs. Topology. Usecases. Examples for single transactions.
>
> But if this were an ignoring cache-control issue, wouldn't that happen on
> squid 3.5.19 and previous versions as well?
>
> With the same conf works on 3.5.19 but not in newest squid3 versions.
Once more. Ignoring cache-control in squid is deprecated due to RFC
requirements. So, it leads to drops down with byte HIT in general. I do
not remember when it exactly desupported in squid's code, but seems
approx. at some 3.5.x.

I can't to say exactly, because of using Squid 5.x branch right now.
>
>
>
> --
> View this message in context: 
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Youtube-not-TCP-HIT-Squid3-5-21-25-tp4682582p4682610.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users




signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Eduardo Carneiro]

Ok. Tell me what technical details you need and I post here.

But if this were an ignoring cache-control issue, wouldn't that happen on
squid 3.5.19 and previous versions as well?

With the same conf works on 3.5.19 but not in newest squid3 versions.



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Youtube-not-TCP-HIT-Squid3-5-21-25-tp4682582p4682610.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Yuri]

To better understanding pls read this and all related:

http://wiki.squid-cache.org/ConfigExamples/DynamicContent

http://wiki.squid-cache.org/Features/StoreID

YT, FB, Vimeo uses dynamic content and requires additional efforts to
make content cacheable (with some restrictions).

The issue your experienced can be related (partially) with dropped
support for ignoring cache-control.

Since you do not bring any technical details, it's hard to say exactly
what you want to achieve and in what way, and also to say that you -
perhaps - are doing wrong.

28.05.2017 20:24, Eduardo Carneiro пишет:
> As I said before, is a more larger problem. not just Youtube. If rewrite is
> necessary, doesn't work the cache. I tried with Youtube, Facebook, Vimeo,
> etc.
>
> Anyway I will try these links that you suggested and put here the results.
> It work very well until Squid 3.5.19. Not in newest versions.
>
>
>
> --
> View this message in context: 
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Youtube-not-TCP-HIT-Squid3-5-21-25-tp4682582p4682608.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users




signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Youtube not TCP_HIT Squid3.5.21-25

[Eduardo Carneiro]

As I said before, is a more larger problem. not just Youtube. If rewrite is
necessary, doesn't work the cache. I tried with Youtube, Facebook, Vimeo,
etc.

Anyway I will try these links that you suggested and put here the results.
It work very well until Squid 3.5.19. Not in newest versions.



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Youtube-not-TCP-HIT-Squid3-5-21-25-tp4682582p4682608.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid TPROXY issues with Google sites

[Vieri]

Hi Alex et al.,

Thank you very much for your analysis and help. I really appreciate it.

Please keep in mind that I'm basically an end-user, a sys-admin. I wish I had 
the time to study Squid's source code. All I can do for now is read the docs 
that so many people have kindly published.

In 99% of my use cases, I only need this:

ssl_bump stare all
ssl_bump bump all

However, some sites simply don't behave well when accessed with Squid TPROXY. 
This is an example I'm reporting regarding access to 
https://accounts.google.com.

The use case is simple. A client browser successfully connects to 
https://accounts.google.com and I can see this in the access log (there might 
be some garbage but I'm posting it all for completeness):

# tail -f /var/log/squid/access.log | grep 10.215.145.8
1495969366.990 90 10.215.145.8 TCP_MISS/302 870 GET 
https://accounts.google.com/ - ORIGINAL_DST/216.58.201.141 text/html
1495969367.089 91 10.215.145.8 TCP_MISS/302 1206 GET 
https://accounts.google.com/ManageAccount - ORIGINAL_DST/216.58.201.141 
text/html
1495969367.165165 10.215.145.8 TAG_NONE/200 0 CONNECT 216.58.201.141:443 - 
ORIGINAL_DST/216.58.201.141 -
1495969367.546452 10.215.145.8 TCP_MISS/200 254275 GET 
https://accounts.google.com/ServiceLogin? - ORIGINAL_DST/216.58.201.141 
text/html
1495969367.684 99 10.215.145.8 TCP_MISS/200 837 GET 
https://accounts.google.com/_/common/diagnostics/? - 
ORIGINAL_DST/216.58.201.141 application/json
1495969367.799218 10.215.145.8 TAG_NONE/200 0 CONNECT 216.58.201.141:443 - 
ORIGINAL_DST/216.58.201.141 -
1495969368.341356 10.215.145.8 TCP_MISS/200 9598 GET 
https://ssl.gstatic.com/accounts/static/_/js/k=gaia.gaiafe_glif.es.QCvs5i6XPsY.O/m=ZJkSm,ssIgD,GJkP8c,HUb4Ab,sy3j,DnoIKd,sy1a,sy1g,YKZpNb,sy19,VI9RTb,sy18,sy24,GEsPC/am=gggAAACgARcEwFGwAlAM/rt=j/rs=ABkqax2H2XpBhaGl4fmxx-IOq5MdI_K9yw
 - ORIGINAL_DST/172.217.9.227 text/javascript
1495969373.609249 10.215.145.8 TCP_MISS/200 9598 GET 
https://ssl.gstatic.com/accounts/static/_/js/k=gaia.gaiafe_glif.es.QCvs5i6XPsY.O/m=ZJkSm,ssIgD,GJkP8c,HUb4Ab,sy3j,DnoIKd,sy1a,sy1g,YKZpNb,sy19,VI9RTb,sy18,sy24,GEsPC/am=gggAAACgARcEwFGwAlAM/rt=j/rs=ABkqax2H2XpBhaGl4fmxx-IOq5MdI_K9yw
 - ORIGINAL_DST/172.217.9.227 text/javascript
1495969393.879248 10.215.145.8 TCP_MISS/200 9598 GET 
https://ssl.gstatic.com/accounts/static/_/js/k=gaia.gaiafe_glif.es.QCvs5i6XPsY.O/m=ZJkSm,ssIgD,GJkP8c,HUb4Ab,sy3j,DnoIKd,sy1a,sy1g,YKZpNb,sy19,VI9RTb,sy18,sy24,GEsPC/am=gggAAACgARcEwFGwAlAM/rt=j/rs=ABkqax2H2XpBhaGl4fmxx-IOq5MdI_K9yw
 - ORIGINAL_DST/172.217.9.227 text/javascript
1495969393.940166 10.215.145.8 TCP_MISS/200 452 GET 
http://detectportal.firefox.com/success.txt - ORIGINAL_DST/23.219.93.219 
text/plain
1495969394.116225 10.215.145.8 TCP_MISS/200 1261 GET 
https://ssl.gstatic.com/accounts/static/_/js/k=gaia.gaiafe_glif.es.QCvs5i6XPsY.O/m=ZJkSm/am=gggAAACgARcEwFGwAlAM/rt=j/rs=ABkqax2H2XpBhaGl4fmxx-IOq5MdI_K9yw
 - ORIGINAL_DST/172.217.9.227 text/javascript
1495969394.204873 10.215.145.8 TAG_NONE/200 0 CONNECT 54.148.190.222:443 - 
ORIGINAL_DST/54.148.190.222 -
1495969394.724488 10.215.145.8 TCP_MISS/200 195 POST 
https://incoming.telemetry.mozilla.org/submit/telemetry/3474d8df-c0c5-454b-916f-20ad7f8cb3f3/main/Firefox/52.0.2/release/20170323105023?
 - ORIGINAL_DST/54.148.190.222 text/plain
1495969399.355223 10.215.145.8 TCP_MISS/200 1261 GET 
https://ssl.gstatic.com/accounts/static/_/js/k=gaia.gaiafe_glif.es.QCvs5i6XPsY.O/m=ZJkSm/am=gggAAACgARcEwFGwAlAM/rt=j/rs=ABkqax2H2XpBhaGl4fmxx-IOq5MdI_K9yw
 - ORIGINAL_DST/172.217.9.227 text/javascript

The client browser successfully renders Google's log-in page where you enter a 
username. However, it is NOT possible to "click next" and enter a password.
No matter what the user does on that page, nothing is logged in 
/var/log/squid/access.log.

The cache log reports errors but they are not necessarily related to this 
client as there are many others actively browsing.

# grep -i error /var/log/squid/cache.log 
2017/05/28 12:55:48 kid1| Error negotiating SSL on FD 93: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed (1/-1/2)
2017/05/28 12:55:48 kid1| Error negotiating SSL connection on FD 90: 
error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate (1/0)
2017/05/28 12:55:49 kid1| Error negotiating SSL on FD 143: error:1409F07F:SSL 
routines:ssl3_write_pending:bad write retry (1/-1/0)
2017/05/28 12:55:50 kid1| Error negotiating SSL on FD 172: error:1409F07F:SSL 
routines:ssl3_write_pending:bad write retry (1/-1/0)
2017/05/28 12:55:55 kid1| Error negotiating SSL on FD 57: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)
2017/05/28 12:55:55 kid1| Error negotiating SSL connection on FD 27: 
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (1/-1)
2017/05/28 12:55:58 kid1| Error negotiating SSL on FD 57: error:1409F07F:SSL 
routines:ssl3_write_pending:bad write retry