<div dir="ltr"><div>I have successfully gotten Squid 3.5.20 to filter both HTTP and HTTPS in transparent intercept mode. With intercept mode, iptables rules redirect port 80 to squid's http_port 800 and HTTPS port 443 is redirected to Squid's https_port 801. It all seems to work exactly as it should.</div><div><br></div><div>I have recently been trying to integrate a urlfilter using url_redirect_program with my Squid implementation, and that works very well, also.</div><div><br></div><div>The problem:</div><div><br></div><div>One of the useful features of the urlfilter is that it detects proxy tunnels and blocks them. Not being very proficient in the use of proxy tunnels and VPNs I wanted to test it out. I setup a VPN client (CyberGhost VPN) on my Linux client connected to my firewall with the Squid implementation and could successfully establish a VPN connection <strong><em>via port 443</em></strong> when Squid and the URL Filter were disabled. After disconnecting the VPN and enabling Squid and the urlfilter, attempting to connect using the VPN over 443 failed to connect.</div><div><br></div><div>Now that actually might be a good thing because I am trying to block it anyway. But the block is an error and not in the manner that is expected. It is blocked, it seems, because the redirection of port 443 to Squid causes Squid to barf on the VPN because the VPN, while using port 443 is not a TLS/SSL encrypted connection and Squid doesn't seem to know what to do with the connection.</div><div><br></div><div>Is there a way to tell Squid that there may be port 443 connections that don't use TLS/SSL so that a useful message could be generated other than the "connection failed" message the VPN client gives? There are error messages in the Squid cache.log about connection attempts failed because of problems with TLS/SSL and certs.</div></div>