Squid is a free web proxy server that can be configured as a web filter.

You can configure a web proxy in one of two modes:

1. Explicit
2. Intercept

In explicit mode, clients must be configured to connect to the proxy using HTTP Connect. Squid can be configured using these instructions for the Raspberry Pi.

Intercept mode means that clients do not have to be configured to connect to the proxy. Instead, web requests are transparently routed through the proxy by a network device. Squid has three modes of intercept proxying:

1. Default
2. Bump
3. Splice

In default mode, the proxy terminates the client request and creates a new HTTP(S) connection to the server. Squid presents the client with its own SSL certificate and can thus decrypt all parts of the traffic. This works fine for HTTP traffic but triggers browser security errors for HTTPS traffic

In "bump" mode, the proxy terminates the client request and creates a new HTTP(S) connection to the server. Squid presents a certificate to the client that mimics the server's certificate and can thus decrypt all parts of the traffic. Browsers may detect this type of man-in-the-middle attack and trigger a security warning.

In splice mode, the packets from the client are forwarded to the server without decrypting. This is the only intercept mode that does not trigger security warnings for HTTPS traffic.

The client normally sends the server hostname in clear text in the SSL handshake as part of SNI. You can configure Squid to "peek" at the server hostname, without decrypting the traffic.

Explicit mode allows you to set up proxy authentication, which cannot be used in intercept mode.

Run Squid on two ports. Port 3128 filters web access for unauthenticated users. Port 3129 allows unfiltered web access. The squid.conf directives are:

http_port 3128
http_port 3129
acl filtered localport 3128
acl unfiltered localport 3129
acl auth_users proxy_auth REQUIRED
url_rewrite_access deny unfiltered
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
http_access allow auth_users unfiltered
http_access allow filtered localnet
http_access deny all

Create a user with the following shell comands:

sudo htpasswd -c /etc/squid/passwd john

Then test:

curl -x proxy:3129 --proxy-anyauth -U john:pw <url>

You can use a Chrome extension to enter your username and password automatically.

I encountered various problems with proxy auth and ended up not using it:

1. Performance: Authenticated users have to go through the proxy, even though their traffic is not filtered. There may be performance impact.

2. Chrome OS support: Chrome OS does not list proxy auth as a fully supported feature. Operating system services such as system updates, time and date settings may not work. My experience was that problems were very difficult to debug. The proxy auth dialog box disappeared for me. I could not get one of our Chromebooks to display an authentication dialog when using the proxy. Another Chromebook worked with proxy auth when a user was logged in with a Gmail account but not with a G Suite account.

3. Chrome policies: The network administrators at our children's school disable the proxy settings on student Chromebooks to prevent students from bypassing the school's controls.

View your squid.conf settings:

cat /etc/squid/squid.conf | grep -v ^# | grep -v ^$

Explicit mode can be tested from the command line using:

curl -x localhost:3128 <url>

When testing intercept mode from your developer machine, you can use the Captive Portal to disable traffic routing through the proxy. Packet traces on the Squid machine are a good way to troubleshoot routing issues.

Add the following to raise the log level in /var/log/squid/cache.log:

debug_options ALL,3 33,9 83,9

Add additional fields to the logs:

logformat sslbump %tl %>a %Ss/%03<Hs %<st %rm %>ru %[un %Sh/%<a %mt %ssl::>sni
access_log daemon:/var/log/squid/access.log sslbump

You can reload the Squid configuration file with:

sudo squid -k reconfigure