Squid3 in SSLBump mode with dynamic certificate generation

Greetings.

Encrypted web traffic is a good thing, but sometimes it’s not at all clear what the user does inside. When entering any https resource via squid, enough lines of this type are written to the logs:

1330231066.104 10 172.26.27.8 TCP_MISS / 200 390 CONNECT mail.google.com:443 - HIER_DIRECT / 173.194.32.54 -
1330241192.883 9 172.26.27.97 TCP_MISS / 200 390 CONNECT mc.yandex.ru:443 - HIER_DIRECT / 213.180.193.119 -
')
It can be seen that at certain times, users went to gmail and Yandex. In principle, that's all we see from the logs. But it is not clear whether the GET or POST request was executed, the full URLs or file sizes are not visible. It is also not possible to check ssl traffic with antivirus program or content inspection programs.

In this article I want to describe the ability of squid to “break down” an ssl connection and have at least some overview of what is happening in https traffic.



Since CentOS has “enhanced” openssl, the squid build with the keys we need does not work.
There are two options for solving this problem.
The first is to climb into the installed files of the installed openssl, then to the sources of the squid and change some lines. And the second is to build a squid with custom openssl.

The first option is too hardcore and leave it aside.

1. openssl

So first we need to build our openssl. It's all pretty simple and no magic:

wget www.openssl.org/source/openssl-1.0.0k.tar.gz
tar -zxf openssl-1.0.0k.tar.gz
cd openssl-1.0.0k

To avoid conflicts with the already installed version of openssl, specify the new path:

./config shared --prefix=/opt/squid/openssl --openssldir=/opt/squid/openssl
make
make install
That's it, openssl is built and ready to use.

2. squid

The assembly of the proxy server is similar to the assembly of any program (configure && make && make install), the only thing is to specify certain keys when compiling:

wget www.squid-cache.org/Versions/v3/3.2/squid-3.2.7.tar.gz
tar -zxf squid-3.2.7.tar.gz
cd squid-3.2.7
./configure --prefix=/opt/squid --enable-ssl --enable-ssl-crtd --with-openssl=/opt/squid/openssl

--enable-ssl - includes support for ssl mode
--enable-ssl-crtd - a separate process deals with the generation of certificates, and not the proxy server itself.
--with-openssl - the path where the custom openssl was installed

make all
make install
So, the squid proxy server is compiled.

3. We generate self-signed certificate

The certificate will be used by the proxy server to create dynamic web site certificates.

cd /opt/squid/etc/
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem

Since the squidCA.pem file contains a private key, we make it readable only for the root user:
chmod 400 squidCA.pem

4. Configure squid

Add the following lines to the squid.conf file

 http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/squidCA.pem always_direct allow all ssl_bump allow all sslproxy_cert_error allow all sslproxy_flags DONT_VERIFY_PEER 

This setting is undesirable to use in the production system, since access is allowed to all https sites with any certificates.

Prepare certificate caching:
mkdir /opt/squid/var/lib
/opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db
chown -R nobody /opt/squid/var/lib/ssl_db
If you have a different UID in the cache_effective_user setting, you should use it instead of nobody.

It is worth noting that if for some reason you have changed your certificate for squid, you must completely clear the / opt / squid / var / lib / ssl_db directory and reinitialize the certificate database.

Set the necessary rights, initialize and run the proxy server:
chown -R nobody /opt/squid/var/logs
/opt/squid/sbin/squid -z
/opt/squid/sbin/squid
check the file /opt/squid/var/logs/cache.log for errors, if there are no errors and there is a string " Accepting SSL bumped HTTP Socket connections at local=[::]:3128 remote=[::] FD 21 flags=9 ", then the proxy server in SSLBump mode is running.

5. user problems

Since in this case we use a self-signed certificate, any visits from https sites through a proxy will show users a certificate error. The reason for the error is that the Issuer of our certificate is not in the Trusted CA list in the browser.
Whatever the errors, we perform the following action.

openssl x509 -in squidCA.pem -outform DER -out squid.der

Now, the resulting squid.der file must be imported into the client browser.
For Internet Explorer:
Tools-> Internet Options-> Content-> Certificates
Select the tab "Trusted Root Certificate Authorities"
Click Import, select the squid.der file and complete the import.

For Firefox:
Tools-> Options-> Advanced-> Encryption-> View Certificates
Select the tab "Authorities"
Click Import, select the squid.der file and complete the import.

Well, in general, that's all. Depending on your fantasies, you now have the opportunity in https traffic to prohibit POST requests, download large files, block access to certain files / folders. You can also deny access to sites whose certificates are issued by non-trusted CAs. Well, the ability to check for viruses.

Thanks for attention,