Squid3 in SSLBump mode with dynamic certificate generation
- Tutorial
Greetings.
Encrypted web traffic is a good thing, but sometimes it’s completely not clear what the user is doing inside. When accessing any https resource via squid, enough lines of this kind 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 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, full URLs and file sizes are not visible. There is also no way to check ssl traffic with an antivirus program or with what kind of content inspection programs.
In this article I want to describe the ability of squid to “break” an ssl connection and have at least some overview of what is happening in https traffic.
Since CentOS has "enhanced" openssl, building squid with the keys we need does not work.
There are two options for solving this problem.
The first is to climb into the inclusive 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.
So, for starters, we need to build our own openssl. Here, everything is quite simple and no magic:
In order to avoid conflicts with the already installed version of openssl, we indicate a new path:
Everything, openssl is assembled and ready to use.
Building a proxy server is similar to building any program (configure && make && make install), this is the only indication of certain keys during compilation:
--enable-ssl - includes support for ssl mode
--enable-ssl-crtd - a separate process is involved in generating certificates, not proxy server itself.
--with-openssl - the path where the custom openssl was installed
So, the squid proxy server is assembled.
The certificate will be used by the proxy server to create dynamic certificates for web sites.
Since the squidCA.pem file contains a private key, we make it readable only for the root user:
Add the following lines to the squid.conf file
This setting is undesirable to use in the production system, since access is allowed to all https sites with any certificates.
Preparing certificate caching:
If you have a different UID in the cache_effective_user setting , then you should use it instead of nobody.
It is worth noting that if for some reason you changed your certificate for squid, you need to completely clear the / opt / squid / var / lib / ssl_db directory and reinitialize the certificate database.
We set the necessary rights, initialize and start the proxy server: we
check the file /opt/squid/var/logs/cache.log for errors, if there are no errors and there is a line "
Since in this case we use a self-signed certificate, any visits to https sites through proxies will show users a certificate error. The cause of the error is the Issuer of our certificate is not in the Trusted CA list in the browser.
That there would be no errors, we carry out the following action.
Now the resulting squid.der file must be imported into the client browser.
For Internet Explorer:
Tools-> Internet Options-> Content-> Certificates
Select the “Trusted Root Certificate Authorities” tab.
Click Import, select the squid.der file and complete the import.
For Firefox:
Tools-> Options-> Advanced-> Encryption-> View Certificates
Select the “Authorities” tab.
Click Import, select the squid.der file and complete the import.
Well, that's all. Depending on your fantasies, now you have the opportunity in https traffic to prohibit doing POST requests, download large files, block access to certain files / folders. You can also restrict access to sites whose certificates are issued by untrusted CA. Well, the ability to check for viruses.
Thanks for attention,
Encrypted web traffic is a good thing, but sometimes it’s completely not clear what the user is doing inside. When accessing any https resource via squid, enough lines of this kind are written to the logs:
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, full URLs and file sizes are not visible. There is also no way to check ssl traffic with an antivirus program or with what kind of content inspection programs.
In this article I want to describe the ability of squid to “break” an ssl connection and have at least some overview of what is happening in https traffic.
Since CentOS has "enhanced" openssl, building squid with the keys we need does not work.
There are two options for solving this problem.
The first is to climb into the inclusive 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, for starters, we need to build our own openssl. Here, everything is quite 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
In order to avoid conflicts with the already installed version of openssl, we indicate a new path:
./config shared --prefix=/opt/squid/openssl --openssldir=/opt/squid/openssl
make
make install
Everything, openssl is assembled and ready to use.
2. squid
Building a proxy server is similar to building any program (configure && make && make install), this is the only indication of certain keys during compilation:
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 is involved in generating certificates, not proxy server itself.
--with-openssl - the path where the custom openssl was installed
make all
make install
So, the squid proxy server is assembled.
3. Generate a self-signed certificate
The certificate will be used by the proxy server to create dynamic certificates for web sites.
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.Customize 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.
Preparing 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 , then you should use it instead of nobody.
It is worth noting that if for some reason you changed your certificate for squid, you need to completely clear the / opt / squid / var / lib / ssl_db directory and reinitialize the certificate database.
We set the necessary rights, initialize and start the proxy server: we
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 line "
Accepting SSL bumped HTTP Socket connections at local=[::]:3128 remote=[::] FD 21 flags=9
", then the proxy server in SSLBump mode is started.5. user problems
Since in this case we use a self-signed certificate, any visits to https sites through proxies will show users a certificate error. The cause of the error is the Issuer of our certificate is not in the Trusted CA list in the browser.
That there would be no errors, we carry out 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 “Trusted Root Certificate Authorities” tab.
Click Import, select the squid.der file and complete the import.
For Firefox:
Tools-> Options-> Advanced-> Encryption-> View Certificates
Select the “Authorities” tab.
Click Import, select the squid.der file and complete the import.
Well, that's all. Depending on your fantasies, now you have the opportunity in https traffic to prohibit doing POST requests, download large files, block access to certain files / folders. You can also restrict access to sites whose certificates are issued by untrusted CA. Well, the ability to check for viruses.
Thanks for attention,