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:eliezer@xxxxxxxxxxxx] Sent: Monday, 8 December 2014 8:33 AM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Cc: Glenn Groves Subject: Re: 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.groves@xxxxxxxxxxxxxxx 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----- 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
