[squid-users] Problem with https://www.google.com and squid interception

[Peter Gross]

On 11/11/2014 11:47 AM, Peter Gross wrote:
> Hi,
> I am a new user of Squid and would first like to thank the developers
> for this excellent software. This is my first post to the mailing list
> ... I have been tasked with setting up quite restrictive web access
> control at work. I plan to use an intercepting squid proxy with SSL
> bump. There will also be WCCPv2 to/from a Cisco IOS router. Since this
> is quite a bit of complexity, I though it prudent to start slowly, in
> steps. So first -- to get my feet wet -- I set up squid (version 3.4.8,
> built using rpmbuild from the src rpm from ngtech) on a home linux
> server (Centos 5.11 -- no Cisco at home) which is also the firewall
> router for my home network. I also decided to start out with plain
> vanilla proxying (no interception -- use browser setting). This worked
> fine. I then tested HTTP interception by changing squid.conf from:
> http_port 3128
>    -to-
> http_port 3128 intercept

Based on a suggestion from Amos Jeffries, I changed my squid.conf 
http_port directives to:

http_port 192.168.101.253:3128
http_port 192.168.101.253:3129 intercept
#https_port 192.168.101.253:3130 intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 
cert=/etc/squid/ssl_cert/myca.pem key=/etc/squid/ssl_cert/myca.pem

Note that the https_port directive is commented out for now because I 
just wanted to get HTTP interception working first. I have changed to 
using the default proxy port of 3128 as a (no-intercept) forwarding port 
and changed the intercept port to use 3129. Also -- and this may be 
important in my case -- I added the squid server internal LAN IP address 
to the http_port directives. This host has multiple NICs and I wonder if 
not specifying the eth1 address (eth0 is for internet access) that 
something weird happened before. In any case going to 
https://www.google.com now works every time (keeping fingers crossed).


> and adding the following rule to my shorewall firewall:
> REDIRECT:info   loc:192.168.101.9       3128    tcp     http
>
> I wanted to test intercepting just one host before turning it on for all
> hosts and wireless devices in my network.
>
> 192.168.101.9 is another Centos PC on my network. Squid is running on
> 192.168.101.253.
>
> The interception seemed to work fine ... access.log showed lots of
> successful proxy activity. Then came the problem: going to
> https://www.google.com failed (not every time, but frequently). If I
> turned off the REDIRECT line in the shorewall rules file and restarted
> shorewall, no problem. This seemed very peculiar because no HTTPS
> traffic should be redirected to the proxy. Here are the errors that
> showed up in cache.log when redirection (NAT-ing) was on:
>
> 2014/11/11 11:03:42 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed on
> local=192.168.101.253:3128 remote=192.168.101.9:34165 FD 11 flags=33:
> (92) Protocol not available
>
> Note that other HTTPS sites worked fine! It appears to be confined to a
> google specific issue.
>
> Thanks for any comments/suggestions you might have,
> --peter