Update: SQUID transparent SSL interception : Squid v3.2

In order to keep this blog post a bit more relevant, there have been some improvements since that post was written. Squid v3.2 has been released earlier this year, making ssl interception more seamless and easier. The new features for HTTPS interception can be found while reading through the man page for http_port:


More specifically:

1. The “transparent” keyword has been changed to “intercept“:

           intercept    Rename of old 'transparent' option to indicate proper functionality.

INTERCEPT is now better described as:

intercept	Support for IP-Layer interception of
			outgoing requests without browser settings.
			NP: disables authentication and IPv6 on the port.

2. In order to avoid more certificate errors when intercepting HTTPS sites, squid now can dynamically generate SSL certificates, using generate-host-certificates. This means the CN of the certificate should now match that of the origin server, though the certificate will still be generated using SQUID’s private key:

SSL Bump Mode Options:
	    In addition to these options ssl-bump requires TLS/SSL options.

			Dynamically create SSL server certificates for the
			destination hosts of bumped CONNECT requests.When 
			enabled, the cert and key options are used to sign
			generated certificates. Otherwise generated
			certificate will be selfsigned.
			If there is a CA certificate lifetime of the generated 
			certificate equals lifetime of the CA certificate. If
			generated certificate is selfsigned lifetime is three 
			This option is enabled by default when ssl-bump is used.
			See the ssl-bump option above for more information.

Looks like the above is an offshoot of the excellent work here: http://wiki.squid-cache.org/Features/DynamicSslCert

Make sure to use the above two features for smoother HTTPS interception – though remember, always warn users that SSL traffic is being decrypted, privacy is a highly-valued right…


Dansguardian : lessons learned

To dis-allow users from connecting to a site via IP rather than URL name (so bypassing filtering unless you use the time consuming forward / reverse lookup feature), uncomment the following line in the bannedsitelist:


To enable syslog, the default dansguardian.conf uses:

# Syslog logging
# Use syslog for access logging instead of logging to the file
# at the defined or built-in “loglocation”
#syslog = on

The line “syslog = on”  is incorrect and should be changed to:

logsyslog = on

The facility and priority used by dansguardian is:

In  order for danguardian to display the category when blocking a site, insert the following line at the beginning of each domain blacklist file:
#listcategory: “name_of_category_here”

A quick script to do insert the above mentioned line into each enabled blacklist (note: be careful, these statements are all one-liners):


#! /bin/bash

categories=`cat /usr/local/etc/dansguardian/lists/bannedsitelist | grep -v “#” | grep “Include” | cut -d “/” -f 8`

for category in $categories

echo ‘#listcategory: “‘$category'”‘ > /usr/local/etc/dansguardian/lists/blacklists/$category/domain.new

cat /usr/local/etc/dansguardian/lists/blacklists/$category/domains | grep -v “#” >> /usr/local/etc/dansguardian/lists/blacklists/$category/domain.new

rm -f /usr/local/etc/dansguardian/lists/blacklists/$category/domains

mv /usr/local/etc/dansguardian/lists/blacklists/$category/domain.new /usr/local/etc/dansguardian/lists/blacklists/$category/domains


In order to modify the blocked page displayed, change the following file: