Re: [squid-users] https issues for google
Hi Eliezer, The command for www.google.com failed to complete the connection with a unknown protocol error: openssl s_client -connect www.google.com:443 -showcerts CONNECTED(0003) 140623996839752:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:766: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 263 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- The command for www.google.com.au, google.com.au AND google.com all got the certificate fine, for example a snipt: openssl s_client -connect www.google.com.au:443 -showcerts CONNECTED(0003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 Server certificate subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=google.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent --- SSL handshake has read 10548 bytes and written 389 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 363AA9E6E5446296B11FC1763C24C0C23D6D4D67E4E0D858CEAA9C3B8172CE9A Session-ID-ctx: Master-Key: 30AC2CE9E8447130F9A4664CEF9399075C5C97602F4908D532540CE3694558AF66D54A5390FAF137BB8121785D0B7BB3 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: - 58 90 ee 84 cd 6d 26 5f-13 10 64 4c df 9a 1d a2 Xm_..dL 0010 - 61 fe 82 ea b8 28 c2 51-6d f4 d9 ac 4c a1 45 be a(.Qm...L.E. 0020 - b4 e0 d0 2e 83 3b 08 f4-e1 20 0f 8d 7a fa 77 9f .;... ..z.w. 0030 - 0b 15 5c a3 6f 36 a7 79-4a 8f 70 af ee 81 0e 34 ..\.o6.yJ.p4 0040 - 78 a0 ba 22 84 62 56 7f-19 37 19 d3 66 bd 9a e2 x...bV..7..f... 0050 - 5b a4 47 29 3d 73 32 a8-f8 2a 29 29 b6 81 1f 9b [.G)=s2..*)) 0060 - 74 bb a9 9a 6f 3a 70 5d-31 7c 5b ba 6c 06 2c 59 t...o:p]1|[.l.,Y 0070 - 14 b9 c8 af d5 3e 05 15-48 52 2e c6 0e c6 31 15 ...HR1. 0080 - 26 2e a6 5f d7 e4 09 dd-24 f7 74 ac 5e bb 00 ea .._$.t.^... 0090 - 39 d8 70 0e ba 87 99 fe-ff 9c 02 cd bf f2 d4 8b 9.p. 00a0 - 2a c2 90 b2 *... Start Time: 1418082857 Timeout : 300 (sec) Verify return code: 0 (ok) -Original Message- From: Eliezer Croitoru [mailto:elie...@ngtech.co.il] Sent: Monday, 8 December 2014 1:21 PM To: squid-users@lists.squid-cache.org Cc: Glenn Groves Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK Glenn, It's unclear on what side the SSL error is. There are issues and the next step would be to try to run some openssl s_client test towards these hosts. An example throw a proxy and directly can be found in the next link: http://stackoverflow.com/questions/3220419/openssl-s-client-using-a-proxy We will see together the results of the basic test of direct connection vs a tunneled connection from the proxy itself and understand better the issue. Eliezer On 12/08/2014 02:25 AM, glenn.gro...@bradnams.com.au wrote: --Iptables is enabled, I suspect this should not be a problem there as some SSL sites work. -- We do not use IPV6, I have tried disabling IPV6 in Centos and leaving as is, no difference there. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUhRkdAAoJENxnfXtQ8ZQUcgoIAIee9Ce5JCNYRt+zIZXdrtEE OzHA9YO1xucI5/xEJlPXvV0x5O4g75HINOyE+K/KII+z/T92Lvfoa4rYmo4D7jxf 0fqjwfP9D3D2Xb58lhlhfdoXD69L36orVKROahCt/xVx5b+lOlQ2NJI3NXDG2GnX UG7nJENWeKW+u2AY9934ydP223cd08q471tmXCZba6bUGCWdC3/IFS7w2XVwbTsU ffiv7dZc1V4q45XgHpeGbqhUKZpFlyJ2zxpqYbW9y+OKpNgfGnn/4GqAheCqeDco t+VE21aiJux0xy7uWVnNj7VVsn3cV3EUBei3UiHZ0AKCoGsRERCt8c2OOmJgcvM= =5R6z -END PGP SIGNATURE- 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 helpd...@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
Re: [squid-users] https issues for google
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glen, Since openssls_client is showing you this error I assume squid received the same response. We do need to verify why the connection is being hangs. For now it seems like not 100% squid related issue. Eliezer On 12/09/2014 01:57 AM, glenn.gro...@bradnams.com.au wrote: Hi Eliezer, The command for www.google.com failed to complete the connection with a unknown protocol error: openssl s_client -connect www.google.com:443 -showcerts CONNECTED(0003) 140623996839752:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:766: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 263 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUiC8XAAoJENxnfXtQ8ZQUTsoH/39dKxH0hacCfys0J1zIy+wi hsgWSsgGUAwAwKwa8uEp8XgAqIEACrpig9MUDXWAqaQYwuufu8HqP6bBUC4PG3mx MGbXrbMc8gEs1+K1pxGEmwph9GruTJKxSlBavxWDcozj6x7x2N7SEXRHvcqoq9SE rqZo16eO5vG3cOLa+rsAA/ouEDVHm55G/MC+647nrztQneW1iKFoDzdTqPKl40kF 9RQZwwbbP7cSCF8RZh5AfJwBNpPQKt0eUisJqcWp4w9Kx7Mz4j0Qk7dVQiQ9vTMD rM8z+8SJfdUdWBnWdUU1Pl5qG0T2BUQHtnkM/lyz4OdRNQnGzXdlaY4KSpybKsA= =tePH -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https issues for google
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? Or more importantly, how to fix my squid 3.1 on centos 6.5 with this problem. Thanks, Glenn -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of glenn.gro...@bradnams.com.au Sent: Thursday, 9 October 2014 9:04 AM To: elie...@ngtech.co.il; squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google Hi Eliezer, The DNS we are using is the ISP default for external, our internal domain DNS for internal. Nslookup works for all tests. I would like to update to the latest stable, but I am concerned of breaking the current setup. It took a little work to get it working correctly particularity on the multiple authentication methods working with our domain and trust. I support what has been said - to check the logs. This will likely take time as I cannot reproduce this issue on demand - and I think users are starting to not report the issue and just living with it (or it is not getting all the way to me at least). I will have to get lucky at some point on my computer and look into it then. Could squid be getting mixed up when mulipule https requests are to the same address (e.g. https://google.com.au)? Thanks, Glenn -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Eliezer Croitoru Sent: Wednesday, 8 October 2014 7:39 AM To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glenn, Since you are not using intercept or tproxy the basic place to look at is the access.log. You can see there if the proxy is trying for example to reach an IPV6 address (by mistake). Also to make sure there is an issue you can use specific exception like the cacheadmin acl you are using to allow the cacheadmin access without authentication for the basic test. Also you are indeed using the latest CentOS 6.5 squid but since the current stable version is 3.4.8 you should try to upgrade(to something else then 3.1) due to other issues. The issue can be a network or dns related issue which was not detected until now. Please first make sure that the access.log and cache.log files are clean for errors or issues. What dns servers are you using? Eliezer On 10/07/2014 06:51 AM, glenn.gro...@bradnams.com.au wrote: Hi All, We have a weird issue where https sites apparently don't respond (get message this page can't be displayed). This mainly affects google websites and to a lesser affect youtube. It has been reported it may have affected some banking sites but this is unconfirmed. We are running centos 6.5 with up to date squid from the centos repositories. Here is the version of squid: yum list installed | grep squid squid.x86_64 7:3.1.10-20.el6_5.3 The https sites work fine if I put a direct hole in the firewall to allow internet traffic directly out - but this is not a solution. Thanks, Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUNF1uAAoJENxnfXtQ8ZQUlfYH/i0o9MQDTt8g5aINRljVSMZc btC8mcYn/JYn4WUPIoOc4/MhvuYg0JO6hXsSoPxjI1khMrq9fTV2c8eaLItWqYCf hjioWPJs2hPwfw6WDi0I6kF0Is+hD/MGsJci7s+jg593lHnm+ZjoDIHj0aCpcdgy u95961yZWXINbYsjTirFftnX5UC5MWbwZjaah6zW84RKZl/pa1vJM/tdgqiLdE5V GDNhS01mbKPfin8oc/RQk4nYAK39vncSebvSHJwkvPJIKlb54Yti64j6qUfPsav3 uUvIVKSpxZjFFJoLtw1zjn1MwyynoHNGT1lP+HptsGkDoeGJ6YWU/IwB1sFKcVk= =GKmE -END PGP SIGNATURE- ___ squid-users mailing list squid-users@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 helpd...@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
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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https issues for google
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-boun...@lists.squid-cache.org] On Behalf Of Amos Jeffries Sent: Sunday, 7 December 2014 7:34 PM To: squid-users@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@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 helpd...@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 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https issues for google
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glenn, I noticed that in the mean while you have upgraded the system to latest 3.4.9 stable. As Amos mentioned there are couple options about the tunneling issues. I am unsure about the issue since in my environment squid seems to not have any issues. I would suggest a testing path for the issue before applying patches blindly. My suggestion is: - - use one and only one client - - run a tracepath from the client to the relevant sites. - - test using wget\curl\script a tunnel request to https:/www.gmail.com/ or https://mail.google.com/ throw the proxy from the mentioned client.(there is a wget binary for windows) - - if the issue accrues to this client try to remove the authentication only for this client ip and try again. The above test will isolate the issue from multiple clients and unknown source to only one. If you are familiar with PMTU or iptables clamping it will help to test it more in depth. I assume that you are using a Linux OS and I would prefer to get some details about it as a starter. Thanks, Eliezer On 10/09/2014 02:04 AM, glenn.gro...@bradnams.com.au wrote: Could squid be getting mixed up when mulipule https requests are to the same address (e.g. https://google.com.au)? Thanks, Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUhNWkAAoJENxnfXtQ8ZQUhjkIAIt13ZuSaMx7HyLYExUmAxPW djzEj9DK6YBEUexeSA5hfIqRFwA0wRXK1a4fAni8J5v7iVqqdLj4Cwnx1C3Jf9Gc fl9pRBbDNl8SMHWUPvxv0PELRgGzjGN76CXHB7aARbAKaOd6raajlbdl0ltro2D6 UyTaAjG2lc2yH/kJAGHsnjpEztkxWezdBWO3SC8Ej4bEdctfRfSEXeZDI0fQsSsg D3vVG/ppGOSnivMfeQiaUSmexhaFI6XO0wrrj4uyeJ/ptVC0ZkikkCDCp3xRWEAt BK0fgRJtUbc7jroqPx7ec+2l3gtZCbK8fMDwPMt2ut5IXevPFO8B4a16dPk40uM= =6hKW -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https issues for google
Hi Eliezer, Thanks for the response, -- I am doing this on a clone of the original proxy with the issue, this frees me up to test, largely I am testing from one client - but try others every now and again to check, it is windows. -- I am not sure as to the idea of the tracepath from the client, it is a windows client so I did try mturoute, but it fails as it is trying to go direct, not through the proxy. If I enable direct in our firewall, the SSL sites work fine. -- In the web browser I found if I go to secure google.com sites I get the errors, if I go to secure google.com.au site I do not. -- I decided to do a tracepath from the proxy itself. Both google.com and google.com.au return the same output: tracepath www.google.com.au 1: Proxy Ext IP (Proxy Ext IP) 0.059ms pmtu 1500 1: firewall gateway (firewall gateway) 0.513ms asymm 2 1: firewall gateway (firewall gateway) 0.384ms asymm 2 2: Internet IP (Internet IP)1.105ms 3: woo6.brisbane.telstra.net (165.228.143.1) 2.540ms 4: tengige0-8-0-2.woo-core1.brisbane.telstra.net (203.50.51.129) 4.136ms 5: bundle-ether11.chw-core10.sydney.telstra.net (203.50.11.70) 15.819ms 6: bundle-ether1.chw48.sydney.telstra.net (203.50.6.154) 23.194ms 7: no reply 8: no reply -- I used wget and test this out: https://www.google.com.au wget -e https_proxy= proxyserver:port https://www.google.com.au converted 'https://www.google.com.au' (ASCII) - 'https://www.google.com.au' (UTF-8) --2014-12-08 09:58:18-- https://www.google.com.au/ Resolving proxyserver (proxyserver)... IP ADDRESS Connecting to proxyserver(proxyserver)| IP ADDRESS |:port... connected. ERROR: cannot verify www.google.com.au's certificate, issued by '/C=US/O=Google Inc/CN=Google Internet Authority G2': Unable to locally verify the issuer's authority. To connect to www.google.com.au insecurely, use `--no-check-certificate'. https://www.google.com wget -e https_proxy=proxyserver:port https://www.google.com converted 'https://www.google.com' (ASCII) - 'https://www.google.com' (UTF-8) --2014-12-08 09:55:29-- https://www.google.com/ Resolving proxyserver (proxyserver)... IP ADDRESS Connecting to proxyserver (proxyserver)|IP ADDRESS|:PORT... connected. Unable to establish SSL connection. -- So this shows that SSL to google.com is a problem through the proxy, but google.com.au is not. I am using linux, it is Centos 6.5, standard install, iptables, 2 interfaces - one for internal traffic to get out, the other on DMZ for the out traffic. --Iptables is enabled, I suspect this should not be a problem there as some SSL sites work. -- We do not use IPV6, I have tried disabling IPV6 in Centos and leaving as is, no difference there. I do not have great experience in iptables of PMTU. On a last note, I did wget on the proxy itself, I did not specify to go through squid so should have gone direct, the problem exists there too, seems squid may not be the issue but I would appreciate if I could have help on the issue: # wget https://www.google.com --2014-12-08 10:14:39-- https://www.google.com/ Resolving www.google.com... 216.58.220.132, 2404:6800:4006:800::2004 Connecting to www.google.com|216.58.220.132|:443... connected. OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol Unable to establish SSL connection. #wget https://www.google.com.au --2014-12-08 10:15:04-- https://www.google.com.au/ Resolving www.google.com.au... 216.58.220.131, 2404:6800:4006:800::2003 Connecting to www.google.com.au|216.58.220.131|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: âindex.htmlâ [ = ] 19,467 --.-K/s in 0s 2014-12-08 10:15:04 (38.8 MB/s) - âindex.htmlâ -Original Message- From: Eliezer Croitoru [mailto:elie...@ngtech.co.il] Sent: Monday, 8 December 2014 8:33 AM To: squid-users@lists.squid-cache.org Cc: Glenn Groves Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glenn, I noticed that in the mean while you have upgraded the system to latest 3.4.9 stable. As Amos mentioned there are couple options about the tunneling issues. I am unsure about the issue since in my environment squid seems to not have any issues. I would suggest a testing path for the issue before applying patches blindly. My suggestion is: - - use one and only one client - - run a tracepath from the client to the relevant sites. - - test using wget\curl\script a tunnel request to https:/www.gmail.com/ or https://mail.google.com/ throw the proxy from the mentioned client.(there is a wget binary for windows) - - if the issue accrues to this client try to remove
Re: [squid-users] https issues for google
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? I've seen that when squid is returning a HTML page (error, denied, not found, etc). Seems strange that a 200 is being logged if that's the case though... Can you do a tcpdump on the traffic and see what is happening, and if the response looks like SSL, or more like plaintext HTML? James ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https issues for google
I was able to capture the log at the time this happened to me, I got the following in the access.log: 1412895309.389 84 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895311.770 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895311.852 77 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895311.855 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895311.937 77 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895311.941 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.053107 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.056 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.124 65 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.680 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.765 79 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.768 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.846 74 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.851 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.927 73 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.931 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html Not sure why it would be saying TCP_MISS, I assume the TCP_DENIED is expected as it happens after the TCP_MISS and has no authentication information. -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of glenn.gro...@bradnams.com.au Sent: Thursday, 9 October 2014 9:04 AM To: elie...@ngtech.co.il; squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google Hi Eliezer, The DNS we are using is the ISP default for external, our internal domain DNS for internal. Nslookup works for all tests. I would like to update to the latest stable, but I am concerned of breaking the current setup. It took a little work to get it working correctly particularity on the multiple authentication methods working with our domain and trust. I support what has been said - to check the logs. This will likely take time as I cannot reproduce this issue on demand - and I think users are starting to not report the issue and just living with it (or it is not getting all the way to me at least). I will have to get lucky at some point on my computer and look into it then. Could squid be getting mixed up when mulipule https requests are to the same address (e.g. https://google.com.au)? Thanks, Glenn -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Eliezer Croitoru Sent: Wednesday, 8 October 2014 7:39 AM To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glenn, Since you are not using intercept or tproxy the basic place to look at is the access.log. You can see there if the proxy is trying for example to reach an IPV6 address (by mistake). Also to make sure there is an issue you can use specific exception like the cacheadmin acl you are using to allow the cacheadmin access without authentication for the basic test. Also you are indeed using the latest CentOS 6.5 squid but since the current stable version is 3.4.8 you should try to upgrade(to something else then 3.1) due to other issues. The issue can be a network or dns related issue which was not detected until now. Please first make sure that the access.log and cache.log files are clean for errors or issues. What dns servers are you using? Eliezer On 10/07/2014 06:51 AM, glenn.gro...@bradnams.com.au wrote: Hi All, We have a weird issue where https sites apparently don't respond (get message this page can't be displayed). This mainly affects google websites and to a lesser affect youtube. It has been reported it may have affected some banking sites but this is unconfirmed. We are running centos 6.5 with up to date squid from the centos repositories. Here is the version of squid: yum list installed | grep squid squid.x86_64 7:3.1.10-20.el6_5.3 The https sites work fine if I put a direct hole in the firewall to allow internet traffic directly out - but this is not a solution. Thanks, Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUNF1uAAoJENxnfXtQ8ZQUlfYH/i0o9MQDTt8g5aINRljVSMZc
Re: [squid-users] https issues for google
Hi, Check the below acl rule in your squid configuration file to Block the particular Domain URLs and also block keywords itself. # ACL block sites acl blocksites dstdomain .youtube.com # ACL block keywords acl blockkeywords url_regex -i .youtube.com #Deny access to block keywords ACLblock sites ACL's http_access deny blockkeywords http_access deny blocksites And check the access.log file in the squid. Regards, ViSolve Squid On 10/10/2014 4:32 AM, glenn.gro...@bradnams.com.au wrote: I was able to capture the log at the time this happened to me, I got the following in the access.log: 1412895309.389 84 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895311.770 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895311.852 77 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895311.855 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895311.937 77 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895311.941 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.053107 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.056 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.124 65 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.680 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.765 79 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.768 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.846 74 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.851 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html 1412895312.927 73 10.10.10.69 TCP_MISS/200 0 CONNECT www.youtube.com:443 MYADUSER DIRECT/74.125.237.160 - 1412895312.931 0 10.10.10.69 TCP_DENIED/407 3983 CONNECT www.youtube.com:443 - NONE/- text/html Not sure why it would be saying TCP_MISS, I assume the TCP_DENIED is expected as it happens after the TCP_MISS and has no authentication information. -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of glenn.gro...@bradnams.com.au Sent: Thursday, 9 October 2014 9:04 AM To: elie...@ngtech.co.il; squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google Hi Eliezer, The DNS we are using is the ISP default for external, our internal domain DNS for internal. Nslookup works for all tests. I would like to update to the latest stable, but I am concerned of breaking the current setup. It took a little work to get it working correctly particularity on the multiple authentication methods working with our domain and trust. I support what has been said - to check the logs. This will likely take time as I cannot reproduce this issue on demand - and I think users are starting to not report the issue and just living with it (or it is not getting all the way to me at least). I will have to get lucky at some point on my computer and look into it then. Could squid be getting mixed up when mulipule https requests are to the same address (e.g. https://google.com.au)? Thanks, Glenn -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Eliezer Croitoru Sent: Wednesday, 8 October 2014 7:39 AM To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glenn, Since you are not using intercept or tproxy the basic place to look at is the access.log. You can see there if the proxy is trying for example to reach an IPV6 address (by mistake). Also to make sure there is an issue you can use specific exception like the cacheadmin acl you are using to allow the cacheadmin access without authentication for the basic test. Also you are indeed using the latest CentOS 6.5 squid but since the current stable version is 3.4.8 you should try to upgrade(to something else then 3.1) due to other issues. The issue can be a network or dns related issue which was not detected until now. Please first make sure that the access.log and cache.log files are clean for errors or issues. What dns servers are you using? Eliezer On 10/07/2014 06:51 AM, glenn.gro...@bradnams.com.au wrote: Hi All, We have a weird issue where https sites apparently don't respond (get message this page can't be displayed). This mainly affects google websites and to a lesser affect youtube. It has been reported it may have affected some banking sites
Re: [squid-users] https issues for google
Hi Eliezer, The DNS we are using is the ISP default for external, our internal domain DNS for internal. Nslookup works for all tests. I would like to update to the latest stable, but I am concerned of breaking the current setup. It took a little work to get it working correctly particularity on the multiple authentication methods working with our domain and trust. I support what has been said - to check the logs. This will likely take time as I cannot reproduce this issue on demand - and I think users are starting to not report the issue and just living with it (or it is not getting all the way to me at least). I will have to get lucky at some point on my computer and look into it then. Could squid be getting mixed up when mulipule https requests are to the same address (e.g. https://google.com.au)? Thanks, Glenn -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Eliezer Croitoru Sent: Wednesday, 8 October 2014 7:39 AM To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Glenn, Since you are not using intercept or tproxy the basic place to look at is the access.log. You can see there if the proxy is trying for example to reach an IPV6 address (by mistake). Also to make sure there is an issue you can use specific exception like the cacheadmin acl you are using to allow the cacheadmin access without authentication for the basic test. Also you are indeed using the latest CentOS 6.5 squid but since the current stable version is 3.4.8 you should try to upgrade(to something else then 3.1) due to other issues. The issue can be a network or dns related issue which was not detected until now. Please first make sure that the access.log and cache.log files are clean for errors or issues. What dns servers are you using? Eliezer On 10/07/2014 06:51 AM, glenn.gro...@bradnams.com.au wrote: Hi All, We have a weird issue where https sites apparently don't respond (get message this page can't be displayed). This mainly affects google websites and to a lesser affect youtube. It has been reported it may have affected some banking sites but this is unconfirmed. We are running centos 6.5 with up to date squid from the centos repositories. Here is the version of squid: yum list installed | grep squid squid.x86_64 7:3.1.10-20.el6_5.3 The https sites work fine if I put a direct hole in the firewall to allow internet traffic directly out - but this is not a solution. Thanks, Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUNF1uAAoJENxnfXtQ8ZQUlfYH/i0o9MQDTt8g5aINRljVSMZc btC8mcYn/JYn4WUPIoOc4/MhvuYg0JO6hXsSoPxjI1khMrq9fTV2c8eaLItWqYCf hjioWPJs2hPwfw6WDi0I6kF0Is+hD/MGsJci7s+jg593lHnm+ZjoDIHj0aCpcdgy u95961yZWXINbYsjTirFftnX5UC5MWbwZjaah6zW84RKZl/pa1vJM/tdgqiLdE5V GDNhS01mbKPfin8oc/RQk4nYAK39vncSebvSHJwkvPJIKlb54Yti64j6qUfPsav3 uUvIVKSpxZjFFJoLtw1zjn1MwyynoHNGT1lP+HptsGkDoeGJ6YWU/IwB1sFKcVk= =GKmE -END PGP SIGNATURE- ___ squid-users mailing list squid-users@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 helpd...@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 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https issues for google
Not sure about turning off the proxy authentication, this would be hard to test as the issue is intermittent. The same with logging as I need to capture the issue. Thanks, Glenn -Original Message- From: Victor Sudakov [mailto:suda...@sibptus.tomsk.ru] Sent: Tuesday, 7 October 2014 7:47 PM To: Glenn Groves Cc: squid-us...@squid-cache.org Subject: Re: [squid-users] https issues for google -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 glenn.gro...@bradnams.com.au wrote: We have a weird issue where https sites apparently don't respond (get message this page can't be displayed). This mainly affects google websites and to a lesser affect youtube. But if you switch off proxy authentication, https sites start working, right? - -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUM7agAAoJEA2k8lmbXsY0SswIAKaYLybj92jJULi16lVfrZgm hrizPJrpJAmLUwh5jtpQETGfc5owS9eyrwczh3dD1BZiLDQp2BUAMdlpG4bpmcFD pLCQhjLZur63/DD/C3hWcch59wceAXFsJa4O2YKC9kFkijnJK+o5K/ixUl2Xbsoy 2VkHYpimXTvEJcRG6P3tpvkUmjl1IzrFtkUdmV7DmJVdacGOFeVu7UCPnXRD97K0 fdtLGH7tTw04PfBJIr985i+Tht+C6uqTQo4W1l41JRIGdSGOxTedYj4dIpvHh9YW KtC4zxrDj+H4H9doOZwPo9sa3vY+HyT2oO2vHur1mPgt1RVmPsO+mo35h7CQj4I= =ZAyn -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
