Chaining Squid to Privoxy

Overview

There are many benefits to chaining squid to privoxy. First you receive additional HTML scrubbing and content controls by adding privoxy to the chain. The squid proxy provides a local cache increasing web performance. Lastly by placing squid between the user and privoxy, you decrease the CPU usage of privoxy.

The most common way to configure squid and privoxy in a chain is to have squid send its requests to Privoxy when then passes the requests to the appropriate server on the Internet. Once the chain is configured, the browser should be configured to make HTTP requests to squid's proxy port. By default, this port is 3128. The below example demonstrates the path an HTTP request will take from a properly configured browser.

Browser -> Squid -> Privoxy -> Privoxy's IP -> Public Internet

Squid Configuration

The configuration below assumes privoxy listens on the localhost and on the default port of 8118. If your configuration differs, make changes as appropriate. Add the following to your /etc/squid/squid.conf at the end of the file.

cache_peer localhost parent 8118 0 default no-query no-digest no-netdb-exchange
never_direct allow all

The first line defines privoxy as a cache_peer. The first argument sets the hostname of the peer to localhost. The second argument sets the type to parent. This means squid should expect to receive HTTP replies from this cache_peer. The third argument specifies the proxy port as 8118. The fourth argument specifies the ICP port as 0. This means it will not send ICP requests to this peer. The last arguments specify the options for the cache_peer. These options are default, no-query, no-digest, no-netdb-exchange. Default allows the parent cache to be used as a "last-resort". This is a recommended option if the parent cache does not use ICP. No-query tells squid not to send ICP queries to this cache. No-digest not send cache digest to this cache. No-netdb-exchange disables ICMP RTT database (NetDB) requests to this cache. All these options and more can be found in /etc/squid/squid.conf.default.

The second line ensures squid never directly sends HTTP requests to the origin server for the ACL element, all. The ACL element, all refers to all possible IP addresses. In this case, squid will never send an HTTP request to the server which should host the content. This forces squid to forward all requests to privoxy.

We need to restart squid for the configuration changes to take effect. The command(s) to do so will differ system to system. The below example demonstrates restarting squid on RedHat based systems.

# /etc/init.d/squid restart

Increasing Privacy

If you wish greater privacy in your web browsing, you may configure squid to remove various HTTP headers in its clients requests. However, please be advised some web sites and/or services will cease functioning properly if certain headers are not present, for example User-Agent. The Tor wiki covers several setups which control HTTP headers. The below example shows the configuration needed in the squid.confto block the From, Referer, Server, User-Agent, WWW-Authenticate and Link headers from being sent to any site.

# The following settings are helpful in removing some sensitive
# HTTP headers which could divulge unwanted information:
#
header_access From deny all
header_access Referer deny all
header_access Server deny all
header_access User-Agent deny all
header_access WWW-Authenticate deny all
header_access Link deny all