Nowadays, most companies control the Internet access of employees through the use of a proxy.
BlueCoat, recently acquired by Symantec, is a leader company in Web Security Services. Regarding proxy appliances, BlueCoat has no competitors.
One of the biggest advantages offered by proxy appliances is the ability to inspect SSL traffic. This is very useful to detect suspicious payloads in requests, downloads of malicious software, control possible leaks of information, etc
In this post we are going to explain how to configure a ProxySG S400-30 appliance (SGOS 18.104.22.168) to be able to inspect the company SSL traffic.
Create the certificate used to intercept SSL traffic
From the administration web console the first thing we should do is create a new keyring. This keyring is the SSL certificate that will be presented to users when browsing HTTPS sites.
For that, navigate to “Configuration > SSL > Keyrings” and click on “Create”:
Click on the new keyring created and press “Edit”. In the “Certificate Signing Request” section, click on “Create”:
Fill in the data of the certificate that will be shown to the users. It is important to take into account the CN field and the encryption algorithm.
Once the CSR is created, click on Edit again and copy the base64 code to a .txt file and rename it with extension .csr:
Once the CSR is obtained, it must be signed by the Root CA (Certificate Authority) of our company PKI. This is really important because our employees web browsers have to trust in this certificate, since users already trust in our company Root CA they will trust in the proxy certificate if it is signed by the Root CA.
When signing the CSR, we must use the SubCA template because the certificate to be installed in the proxy must be able to issue certificates emulating the certificates of the HTTPS websites visited by the users.
To sign the CSR we can use the following command from our Active Directory Server:
certreq.exe -attrib "CertificateTemplate:SubCA" -submit <CSR_file>
Once signed and obtained the inspection certificate, it must be converted to base64 .cer format in order to be imported into the proxy keyring. To convert it to base64 you can use the native Windows “certutil” tool. Ex:
certutil -encode <signed_certificate> base64_certificate.cer
Finally, in the administration web console go to “Configuration> SSL> Keyrings” and edit the keyring created for the interception. Add the base64 code of the proxy certificate and click “Close” then “Apply”.
Import Root CA and Sub CA certificates to ProxySG
From administration web console navigate to “Configuration > SSL > CA Certificates”go to the “CA Certificates” tab and import the base64 .cer format certificates from both the Root CA and the Sub CA of your company PKI.
Now navigate to “Configuration> SSL> CA Certificates” in the “CA Certificate Lists” tab, select the “browser-trsuted” list and click on “Edit”. Add the imported CA certificates to the list.
In this way the proxy will also trust in our company certificates signed by our CA. You must take into account that when proxy inspects SSL traffic by default it will block all websites whose certificates are not valid or are not signed by a CA in which proxy trusts.
Add the SSL interception policy and enable the protocol detection
From the web administration console, open the Visual Policy Manager (Settings> Policy> Visual Policy Manager> Start). Add a new layer of SSL interception, by clicking on “Policy > Add SSL intercept layer”:
Add one or more rules specifying the source objects for which the inspection will be enabled and as an action select the object “SSL Interception”.
Mark the option “Enable HTTPS interception” and select as Issuer Keyring the proxy certificate that we created in the first steps:
NOTE: In case Skype/Office365 communications go through the proy, it will be necessary to check the option “Enable SSL interception with proxy handoff” as described in the next post.
Finally go to “Configuration > Services > Proxy Services” and choose the service where you want to enable the SSL interception. Usually, in explicit deployments this is the HTTP service where all clients HTTP/HTTPS requests will go to 8080 port.
Click “Edit Service” and enable the option “Detect Protocol”. Then click Apply.
Make sure your employees browsers trust in the Root CA of your PKI
When SSL interception is enabled, the proxy will present spoofed SSL certificates signed by itself to users when navigating to HTTPS sites. Since those spoofed certificates are signed by the company Root CA, users should trust in that Root CA.
Root CA certificates can be deployed easily to users workstations via GPO (Group Policy Objects). Internet Explorer and Chrome will use the Windows certificates store, so there will be no problem with those browsers.
The headaches come when users use Firefox as web browser. Firefox doesn’t use Windows certificates stores, it uses its own certificates store. Here is a way to deploy Root CA certificates in the users’ Firefox browsers:
1 – In Firefox browsing bar write “about:config” and enable the option:
security.enterprise_roots.enabled = true
2 – Root CA certificates must be installed in:
3 – To check if your company Root CA certificates are installed in this store, you can execute the following command from the Windows console.
certutil –viewstore –enterprise root
4 – If after executing that command, the Root CA certificate does not appear in the list, then Firefox will not be able to import that certificate. You should then search where is stored the company Root CA certificate in the following stores:
5 – With a simple PowerShell command you will be able to copy the Root CA certificate to the proper store where Firefox can import it:
Copy-Item HKCU:\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\69D85EC7692C3E62725A369709778FCD8AC09426 HKLM:\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates