Tor, i2p and other Darknet relays can be set-up by chaining various proxies. A good ground to do so is that there are no proxy servers that do not have any defects or can offer the necessary flexibility or supporting features to use Tor:

• squid can forward to other HTTP-based proxies, otherwise, it must be recompiled to support SOCKS.
• polipo can forward to SOCKS proxies - such as Tor, but polipo has no intercept option (and for good reasons, as the author claims).
• privoxy can forward both to SOCKS and to HTTP, but has a slow filtering system and is not a caching proxy.
• tinyproxy has to be patched to support SOCKS upstream proxies, the filtering system consumes a lot of memory and it is not a caching proxy.

This leads to the generic topology documented in many places on the Internet:

In fact, the Vidalia bundle offered by the Tor website follows the same generic set-up out of the box.

This setup assumes the following:

• Clearnet will be browsed directly, without Tor.
  • .onion domains will be browsed through Tor.
  • Some clearnet domains may be specified to be accessed through Tor (potentially bypassing ISP censorship).
• Advertisements will be filtered.
• Clearnet and .onion data may be cached or logged - still proceeding on the assumption that you do not intend to store dodgy files on your machine.
• HTTP connections will be either intercepted or hinted to using proxy auto-discovery.

1. Proxy auto-discovery has to be set-up to hint to a proxy on port 8118.
2. Tor has to be set-up to listen on 127.0.0.1 and port 9050 for SOCKS connections and on 127.0.0.2 and port 53 for DNS queries.
3. i2p is preconfigured to listen on 127.0.0.1 and port 4444.
4. Bind will be configured to forward requests for the .onion domain to Tor on 127.0.0.2 and port 53.
5. Polipo will be configured to filter and cache requests from privoxy.
6. Privoxy will be configured to:
   • forward clearnet requests to polipo on 127.0.0.1 port 8123.
   • forward .onion domain requests to Tor via SOCKS on 127.0.0.1 and port 9050.
   • forward .i2p requests to i2p on 127.0.0.1 and port 4444.

Proxy-autodiscovery requires a webserver, configured to serve a wpad.dat file. DHCPd can hint to the wpad.dat file using the following configuration directives:

option proxy-auto-discovery code 252 = text;
option proxy-auto-discovery "http://192.168.0.1/wpad.dat";

where http://192.168.0.1/wpad.dat is the URL to a local webserver serving wpad.dat. The wpad.dat file can have the following contents:

wpad.dat

function FindProxyForURL(url, host) { 
    if (isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||
        isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0") ||
        shExpMatch(host, "localhost") ||
        shExpMatch(host, "*.local") ||
        isPlainHostName(host))
        return "DIRECT";
    return "PROXY 192.168.0.1:8118"; 
}

For Windows clients, a proxy.pac should be set-up using the same contents of the wpad.dat and served by the web-server.

For more details, please see the proxy auto-discovery page.

The relevant configuration lines in Tor, are the following:

SocksPort 9050
SocksListenAddress 127.0.0.1
SocksPolicy accept 127.0.0.1
VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
DNSPort 53
DNSListenAddress 127.0.0.2
AutomapHostsSuffixes .exit,.onion 

and further tweaking can be done using the speed tweaks on the FUSS page.

Debian-based distributions can fetch the i2p package from the official i2p Debian page. Otherwise, i2p can be downloaded from the official download page. Squeeze users will have to download the source-code from the second address and compile it:

cd /usr/src/
wget -c http://mirror.i2p2.de/i2psource_0.9.6.tar.bz2
tar -jxvf i2psource_0.9.6.tar.bz2
cd i2p-0.9.6/
ant pkg
java -jar i2pinstall.exe -console

ant can be installed on Debian using aptitude install ant. Assuming that the installation directory was chosen as /opt/i2p, some changes to /opt/i2p/i2prouter have to be made.

First, create a group and user for i2p:

groupadd i2p
useradd -g i2p -d /opt/i2p i2p

and change permissions on /opt/i2p, with:

chown -R i2p:i2p /opt/i2p

Next, edit /opt/i2p/i2prouter and set:

RUN_AS_USER="i2p"

Finally, start i2p with:

/opt/i2p/i2prouter start

and install i2p with:

/opt/i2p/i2prouter install

which will create a link from /etc/init.d/i2p to i2prouter so that i2p boots when the system starts up.

For a monit script see the i2p monit page.

Bind will need to forward .onion requests to Tor's DNS resolver. This can be accomplished by adding a forwarder zone to named.conf.local:

zone "onion" {
        type forward;
        forwarders { 127.0.0.2; };
        forward only;
};

This will make any queries for any .onion domains go to 127.0.0.2 and port 53 where Tor will be listening.

The relevant lines in polipo's configuration are the following:

proxyAddress = "127.0.0.1"
proxyPort = 8123
allowedClients = 127.0.0.1

and polipo can be tweaked using the polipo speed tweak guide.

Additionally, for advertisement filtering the following directive can be added:

forbiddenUrl = about:blank

and the domain.txt file from our spam database should be downloaded and copied to /etc/polipo/forbidden.

The following line will make privoxy listen on 192.168.0.1 and port 8118:

listen-address  192.168.0.1:8118

this is where browsers are hinted to connect after fetching wpad.dat.

Privoxy can then forward requests via different routes using the following configuration directives:

## By default, everything goes through polipo
forward /       127.0.0.1:8123

## .onion domains go through Tor
forward-socks4a .onion  127.0.0.1:9050 .

## .i2p domains go through i2p
forward .i2p  127.0.0.1:4444 .

## Requests to thepiratebay.sx go through Tor
forward-socks4a .thepiratebay.sx        127.0.0.1:9050 .

## Requests to some local site are fetched directly without being proxied.
forward mysite.internal  .

Some header filtering is possible for privoxy using the censoring headers guide.

Recent Squid versions have changed the way that SSL interception works. The necessary changes for the Squid 4.x configuration file are the following:

# Port for both HTTP and HTTP(s) interception.
http_port 0.0.0.0:8123 ssl-bump cert=/etc/squid/certs/proxy.pem generate-host-certificates=on dynamic_cert_mem_cache_size=8MB

# Bump all domains.
acl DiscoverSNIHost at_step SslBump1
ssl_bump peek DiscoverSNIHost
ssl_bump bump all


# Start the dynamic certificate generator.
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db -M 8MB
sslcrtd_children 32 startup=5 idle=1
sslproxy_cert_error allow all

The main problem with intercepting SSL and dynamically generating certificates is that all bumped requests would have to be fetched directly. In fact, examining the Squid access log, all requests to SSL bumped websites would appear with HIER_DIRECT since the resources are fetched. To work around this issue, tun2socks can be used with packet mangling to transparently pass all HIER_DIRECT requests through Tor.

That being said, the following ACL can be added to the Squid configuration:

acl HTTPs port 443

and all packets matching HTTPs can be marked with the identifier 0x32:

tcp_outgoing_mark 0x32 HTTPs

Now, given that the tun2socks guide is followed, all resources that would have been retrieved directly will instead be retrieved through Tor.

Privoxy can act as an intercepting proxy, without the need for proxy-autodiscovery. Nevertheless, "Juliusz", makes a compelling argument that http sessions should not be intercepted at the packet level.

The following reasons are summarized and expanded upon:

• HTTP does not happen on the packet level, iptables can be used to feed packets on squid's application layer which in turn assembles them.
• Placing an intercept proxy is literally a MIM attack on yourself - if some site does not show up for some reason, it may be the intercepting proxy's fault and you may think that the site is broken which may not be the case.
  • Having an elegant toggle to either go through a proxy or directly will help you determine if that's the case.
• Some websites, such as banking websites, are picky about proxies. Having an intercept proxy handle all your HTTP traffic may not work well.

"Juliusz" claims that the proxy auto-discovery features do not work well although OSX seems to honor the hints pretty well. In that sense, OSX's proxy configuration takes place on the OS network layer and is honored by every application, not just by browsers.

Although this setup may seem complicated, it is in fact quite flexible:

• You can use privoxy to diverge traffic through either polipo, tor and perhaps i2p.
  • You can use privoxy's advanced filter to censor your headers.
• You can toggle the proxy on and off by disabling proxy auto-discovery on the requesting client machines.
• You can filter advertisements conveniently using polipo's fast blocking routines.