Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

Squid http(s) transparent proxy with Juniper SRX | part 1

How to intercept HTTP/HTTPS connections with Juniper SRX, FreeBSD and Squid -part 1

In this article, I will share my config, thoughts and resources on setting up a transparent proxy for both HTTP connections and HTTPS (man in the middle).

This is only for proof of concept purpose.


What needs to be known:
- when a browser is set up to use a proxy, it will send commands in following format "CONNECT http://www.website.com", intercepting http/https connections means that the browser and of course, user are not aware of any proxy in between.

For this, the squid proxy has to know and the "intercept" (and "transparent" for squid 3.1 and below) keyword for the port that it will listen to has to be given.

- HTTPS connections cannot just be intercepted transparently. This is because of the certificate signature trust mechanism implemented in the browsers. To overcome this, I will use a custom CA and will import the CA certificate in the browser, as a Trusted Certificate Authority, to avoid security warnings regarding the certificate.

- up until and including Squid 3.1, a packet hitting squid intercept/transparent port allowed for destination nat from external router/firewall so that the destination IP address of the packet to be the ip of squid. Starting with squid 3.2 this is still valid, but as a security SQUID needs to check the NAT table for the original destination IP address if it is indeed the IP of the host in the http request. This means that if the traffic is passing through an external box (like my case), it needs to be directed to squid FreeBSD/Linux with original destination ip. Details below on squid changes:
ftp://ftp.itb.it/Squid/pub/squid/squid- ... html#ss2.1
http://web.nvd.nist.gov/view/vuln/detai ... -2009-0801
http://www.squid-cache.org/mail-archive ... /0061.html


The above means that an Junos device (SRX firewall in this case), instead of doing destination nat, it has to use different next-hop for packets with tcp destination ports [ 80 443] and keep same destination ip address.
Juniper calls this source based routing (more or less, here).

- Squid 3.2.9 and 3.3.3 (up until versions released on 26 of April 2013) compiled against OpenSSL 1.X will produce core dumps in certain situations ( if an OpenSSL method SSL_get_certificate is called before the cert is sent to client). See http://bugs.squid-cache.org/show_bug.cgi?id=3816

- the firewall doing NAT is actually FreeBSD PF running on the FreeBSD box. This way, squid has access to NAT table.
!!!!!!!!!! make sure /dev/pf has read permissions for squid user otherwise you will bang your head against first wall !!!!
This is a quick fix (set appropriate in your case).

Step 1. Installing Squid 3.3.4 on FreeBSD 9.1

As mentioned, my FreeBSD system is running openssl 1.0.1e and squid is linked to it's libraries.

Step 2. Squid transparent proxy configuration for http on port 3128 and HTTPS on port 3129

I'm using NSS labs trusted CAs (FreeBSD port ca_root_nss-3.14.3), but you can use whatever bundle you trust.

Before starting squid, the ssl_db directory needs to be initiated:

!!!!Very important to set the correct owner on this directory

/usr/local/etc/squid/ssl/myCA.pem file is a self signed CA bundle containing CA key and CA public file. This bundle will be used by squid to sign dynamic certificates (generate-host-certificates=on) for all SSL domains it will intercept.

The CA certificate needs to be imported in all the browsers in the network to avoid security warnings.