Proxy - a Squid proxy with SSL interception behind firewalld

In 2018 the servers of a management infrastructure in two datacenters got their way to the internet through one Squid forward proxy per datacenter on Red Hat Enterprise Linux 7.5, with two interfaces, a firewalld zone per interface that drops everything not listed, and SSL interception: Squid holds a CA certificate of its own, looks at the TLS handshake of every connection, lets the excluded servers through untouched and re-signs the rest with a certificate generated on the fly, which the servers trust because the CA was deployed to them. I built it in a lab first, then on the two production machines, and renewed the certificate by hand when it expired. Why the traffic had to be intercepted rather than tunnelled my notes do not say; the only client they show is pip.

This Solution is that work, written up from my working notes: the lab build on a VMware guest, the firewalld configuration of both production proxies with every rich rule as it was entered, the Squid configuration with its SSL-bump steps, the certificate renewal on each host (the notes are filed under 2018 and 2019), the SELinux module that let Squid's certificate generator write its database, and the one client problem that showed what interception costs. The notes are thin in places and say so: the production squid.conf is known only from its two port lines, and nothing of the automation that deployed the CA to the servers is in them.

The system in one picture

flowchart LR
  subgraph clients["Clients, zone internal"]
    srv["Servers in the RFC 1918 ranges and 2001:db8::/32"]
    ans["Ansible hosts"]
    sen["Sensu hosts"]
  end
  subgraph prx["dc1-a-vcprx001 or dc2-a-vcprx001, RHEL 7.5"]
    ens3["ens3 internal, target DROP"]
    squid["Squid 3.5, port 3128, ssl-bump"]
    ens4["ens4 external, target DROP, no masquerade"]
  end
  inet["Internet"]
  srv -- "TCP 3128, ICMP" --> ens3
  ans -- "TCP 22" --> ens3
  sen -- "UDP 161" --> ens3
  ens3 --> squid
  squid --> ens4
  ens4 --> inet

The fictional environment

Every Article and every Config document uses the same names and addresses.

The address plan is the one of the Email and NetApp Solutions; the generic RFC 1918 ranges in the rules are what the notes really used. The vendor parts of the MAC addresses are real, their serial parts are not.

Articles

Read in this order; it is the order the work was done in.

Configuration

Each document holds one file, one command set or one listing as it was used, with comments and a check against the current release. The notes show no firewalld file, so its documents are the command sets as they were run, with the output of the checks.

Network and firewalld

Squid

Certificates, SELinux and the client test

What the write-up found

Reading the notes again turned up things I did not see when I wrote them. Each is told in its Article.