[squid-users] Difference between Squid 3.1 & 3.4 regarding HTTPS CONNECT handling
Andrew Wood
andrew at perpetualmotion.co.uk
Thu Jul 9 13:05:09 UTC 2015
Ive had Squid 3.1 running on a Debian 7 server for a couple of years
working in intercept mode for HTTP traffic and using WPAD to force HTTPS
to be CONNECT tunneled through Squid and it works fine.
Im now trying to set up a similar system for someone else using Squid
3.4 which is the version in Debian 8. Everything is configured
identically between the two as I copied the iptables rule file and the
squid.conf file over, the only thing changed was the IP address ranges
for the LAN
HTTP intercept is working OK but HTTPS connect requests are being
refused. Despite the fact that the WPAD file had been updated with the
new IP address and is being served correctly from lighttpd.
I can only conclude therefore that there is some difference between
Squid 3.1 and 3.4 which means it no longer likes my configuration.
Below is the Squid.conf file
VLAN1 is the staff LAN with IP addresses 192.168.10 and VLAN2 is the
public Wifi LAN with IP addresses 192.168.100
Is there anything here in the squid file which Im doing wrong?
Many thanks
#squid.conf:
#set which port to accept clients on & which interfaces to accept clients on
http_port 192.168.10.254:3128 intercept
http_port 192.168.100.254:3128 intercept
#set delay pool to do bandwidth throttling on VLAN2
delay_pools 1
delay_class 1 2
delay_parameters 1 250000/500000 125000/500000
#ORd
acl AllUsers src all
acl ToSentryBoxVL1 dstdom_regex ^192.168.10.254$
acl ToWPADServer dstdom_regex ^wpad.commsmuseum.local$
acl ToPublicWiFiGateway dstdom_regex ^192.168.100.254$
acl PublicWiFiLAN src 192.168.100.0/24
acl PrivateLAN src 192.168.10.0/24
acl DestinedForPrivateLAN dst 192.168.10.0/24
acl DestinedForPublicWiFiLAN dst 192.168.100.0/24
acl ProhibitedSitesDomains dstdomain "/var/squidblacklist.org/domains.squid"
acl IPAddressForHostname dstdom_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$
acl SafePorts port 80 443
acl SSLPorts port 443
#block users tunneling
acl CONNECT method CONNECT
http_access deny CONNECT !SSLPorts
#disable caching
cache deny all
#add VLAN2 to delay pool 1
delay_access 1 allow PublicWiFiLAN
#force traffic coming in on VLAN2 to go out on VLAN2
tcp_outgoing_address 192.168.100.254 PublicWiFiLAN
tcp_outgoing_address 192.168.10.254 PrivateLAN
#block traffic between VLAN1 & VLAN2
#iptables does this for everything EXCEPT stuff coming through Squid
#because iptables sees stuff coming out of squid as originating from the
localhost
#hence iptables FORWARD rules dont apply
http_access deny PublicWiFiLAN DestinedForPrivateLAN
http_access deny PrivateLAN DestinedForPublicWiFiLAN
#show splash screen to new users on public wifi to show t&c etc
#pass session length as arg to perl script cache +ve & -ve responses for
0 secs so
#perl script is always called. Script is responsible for deciding how
long a session is valid for
#%SRC passes client ip on stdin
external_acl_type currentsessiontype ttl=60 negative_ttl=0 %SRC
/var/publicwifisessions/checksession.pl
acl currentsession external currentsessiontype
#will stop on first of these which matches so watch order!
http_access deny ProhibitedSitesDomains
http_access allow ToPublicWiFiGateway
http_access allow ToSentryBoxVL1
http_access allow ToWPADServer
http_access deny CONNECT PublicWiFiLAN !currentsession
http_access deny PublicWiFiLAN !currentsession
http_access deny IPAddressForHostname
http_access deny !SafePorts
http_access allow PrivateLAN
http_access allow PublicWiFiLAN
http_access deny AllUsers
More information about the squid-users
mailing list