[squid-users] https issues for google

Sun Dec 7 20:46:35 UTC 2014

Hi All and Amos,

Thanks for correcting me on thinking that was an error.

Even though squid is logging TCP_200, the browser states the proxy server is not responding. This is again only with secure sites, mainly google sites. It is fairly reproducible now with google mail.

On IE, the error is :the proxy server is not responding"
On Chrome: "ERR_SSL_PROTOCOL_ERROR"
On Firefox "ssl_error_rx_record_too_long"

If I bypass the proxy and go direct to the internet through our firewall, it works fine.

This suggests to me, without having any errors in squid to go by, that squid is doing something to the SSL record. What can I do to try and fix or diagnose? 

Thanks,

Glenn

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Amos Jeffries
Sent: Sunday, 7 December 2014 7:34 PM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] https issues for google

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/12/2014 9:48 p.m., glenn.groves wrote:
> Hi All,
> 
> I have finally been able to spend time upgrading a server to a later 
> squid version, I have tried 3.4.9.
> 
> I could not get authentication to work for this test, but proceeded to 
> test without (also dismisses auth as the problem).
> 
> I am getting the following in the logs with secure sites now the squid 
> is 3.4.9:
> 
> 192.168.9.69 TCP_MISS/200 295 CONNECT www.google.com:443 -
> HIER_DIRECT/216.58.220.1 192.168.9.69 TCP_MISS/200 0 CONNECT
> www.google.com:443 - HIER_DIRECT/216.58.220.132
> 
> Upgrading to 3.4.9 on Centos as been a pain so far, no point in 
> proceeding with the problem persisting. Can someone advise why I am 
> getting TCP_MISS/200 when going to secure google sites?
> 

"200" because the tunnel was setup successfully.

"TCP_MISS" because a connection being opened does not use an existing cache object. Old Squid versions do not use the TCP_TUNNEL label.

The above appear to be successful tunnels setup through the proxy.

> Or more importantly, how to fix my squid 3.1 on centos 6.5 with this 
> problem.
> 

What browser(s) are showing the problem? and what does a tcpdump trace of the packets content show happening?

A) It could be they are trying to use SPDY or HTTP/2 inside the tunnel. CONNECT technically could be followed immediately with traffic bytes even though the tunnel/Upgrade process was not confirmed successful by the proxy. Squid does not support that behaviour until version 3.4.5 (bug 3371) but browsers using SPDY and HTTP/2 rely on it.

You may be able to backport the bug fix
(http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13126.patch),
but this is one unlikely to be easy across so many versions. There have been numerous tunneling code updates in between.

B) It could be happy-eyeballs algorithm being used by the browser.
Settign up a connection in advance and having it timeout in the proxy before an attempt to actually use it is made. Although Squid should append _TIMEOUT to the MISS tag in those cases its not certain if that happens on tunnels.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUhB8iAAoJELJo5wb/XPRjfsIH/jFvpT7a/lHZfM8uaMxoUVu4
oGLoyjx6m1ZEg/W5Ta+TjlnfJjcyqfZdkHeIJzY9athcAWaxcT/By2sFEhuPqdtJ
hbps9UWbcae3Uu8sL71oABPnNvfH23HpU6q3PBrNRv82K8jrFjS56oEFwCQrKavP
pxfirbNk0MZg9/bLDAGnD05ItKAxo+uQ2xQU0AE/z6z3LE23WaMS4axTNLBS2icP
V9y2D90mH35nMlaFkhSPl1oL8HfQ1yOuKoNJz2YSgIsgiEmGBsF9aRQ+FS1CgiSh
HFFDyY+dAQUOFL9Qv/gJjddWhQAqH3X6kjqUCqgzqp+eHCOfrQGWzG6Wv42X7/k=
=P6Ev
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

This message (including any attachments) is confidential and may be legally privileged. If you are not the intended recipient, you should not disclose, copy or use any part of it - please delete all copies immediately and notify the Bradnam Group Helpdesk at helpdesk at bradnams.com.au 

Any information, statements or opinions contained in this message (including any attachments) are given by the author. They are not given on behalf of the Bradnam Group unless subsequently confirmed by an individual other than the author who is duly authorised to represent the Bradnam Group (or any of its subsidiary and associate companies).

All sent and received email from/to the Bradnam Group (or any of its subsidiary and associate companies) is automatically scanned for the presence of computer viruses, security issues and inappropriate content.

For further information on the services which the Bradnam Group provides visit our web 
site(s) at www.bradnams.com.au or www.nationalglass.com.au