July 5, 2012
Posted by on
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:
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…
September 29, 2011
Posted by on
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:
A quick script to do insert the above mentioned line into each enabled blacklist (note: be careful, these statements are all one-liners):
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: