SSL Interception on Proxy SG
Proxy SG allows for interception of HTTPS traffic for Content Filtering and Anti Virus, and for Application Acceleration. This document describes how to setup a demonstration of SSL interception and how to integrate with a Certificate Authority. Integration with Microsoft Certificate Services in Active Directory and a standard OpenSSL implementation will be described. This document does not cover SSL certificate validation, exceptions, or acceptable use policy, but only the processes involved in transparent interception
How Proxy SG Intercepts
When Proxy SG intercepts an HTTPS request, it first connects to the webserver as a client and opens an SSL connection. From this connection the Certificate common name (CN) is received and is used to generate a new server certificate to be presented to the client in the original request. When the client is part of Active Dirctory or part of an existing PKI solution, the certificate generated by the SG can form part of a certificate chain and therefore is fully trusted by the client.
Thus, a certificate signed by ordinarily signed by Versign and its intermediate:-
Setting up a Certificate Authority with OpenSSL
Installing Cygwin, or just OpenSSL, will install a the tools necessary to create a Certificate Authority (CA). The steps necessary to represent a live implementation are two fold. Firstly create a root CA, and then create an Intermediate CA. The Intermediate CA is used to generate the server certificates on the SG. The Root CA is would be trusted by all machines in the PKI Infrastructure/AD.
Create CA Directories mkdir /var/ca cd /var/ca/
mkdir certs crl newcerts private echo "01" > serial
cp /dev/null index.txt cp /usr/lib/ssl/openssl.cnf . Create the CA:
# generate a private key
openssl genrsa -des3 -out private/cakey.key 4096 # create a self-signed certificate valid for 5 years
openssl req -new -x509 -nodes -sha1 -days 1825 -key private/cakey.key -out cacert.pem
The CA certificate should be loaded onto any workstation that will be intercepted transparently. This is analogous to the workstation being in Active Directory, where part of joining the domain is that the Domain Root Certificate is installed on the workstation.
Create the Intermediate CA: cd /var/ca/
mkdir ca2008 cd ca2008 cp ../openssl.cnf .
mkdir certs crl newcerts private echo "01" > serial
cp /dev/null index.txt Intermediate CA private key: #generate the key
openssl genrsa -des3 -out private/cakey.pem 4096 #generate a signing request (valid for 1year)
openssl req -new -nodes -sha1 -days 365 -key private/cakey.pem -out ca2008.csr
Sign Intermediate CA mv ca2008.csr .. cd ..
openssl ca -extensions v3_ca -days 365 -out ca2008.crt -in ca2008.csr -config openssl.cnf –keyfile ./private/cakey.key
mv ca2008.* ca2008/ cd ca2008/
Import into SG
Open Management console https://<cacheip>:8082/ and select SSL->keyrings Click Create
Select show-keypair, and import keyring.
Open the Intermediate CA private key created above in notepad, and copy the contents, paste it into the window. Enter the password for the private key when the key was created
Click OK, then Apply.
Next, open the Intermediate CA Certificate in notepad, and copy the sections between ---BEGIN CERTIFICATE--- and CERTIFICATE---END CERTIFICATECERTIFICATE--- (Inclusive) to the clipboard.
Now, select the new KeyPair, and click “Edit/View”.
Click Close, then Apply.
Next, select “CA Certificates” from under the SSL Menu.
Open the Root CA Certificate in notepad and copy the text between ---BEGIN CERTIFICATE--- and ---END CERTIFICATE--- (Inclusive) to the clipboard.
Select Import, and give the CA a name (“OpenSSLInterceptRoot”).
Paste the contents of the clipboard into the “CA Certificate PEM” Box. Click OK
Opent the Intermediate CA Certificate in notepad and copy the text between BEGIN CERTIFICATE and ---END CERTIFICATE--- (Inclusive) to the clipboard.
Select Import, and give the CA a name (“OpenSSLInterceptIntermediate”). Paste the contents of the clipboard into the “CA Certificate PEM” Box. Click OK Click Apply.
The necessity of adding the Root CA and the Intermediate CA certificates into the CA Certificates session on the SG, is to ensure that when the SG sends the server certificate to the client during interception, that it includes the Intermediate and Root certificates (a chain) in the response. Remember that the client will trust the Root CA certificate, but knows nothing of the Intermediate Certificate so it should be provided with the Server Certificate so that the client can check authenticity back to the Root CA.
At this point, the SG has the Intermediate Certificate installed and is ready to be configured for Interception and client testing.
Certificate Server to generate the necessary intermediate certificates onto the SG to integrate seamlessly with the enterprise
Assuming 2003 Enterprise Server is installed as an Active Directory server. Install IIS and Certificate Authority with Web Enrollment. The Web Enrollment simplifies the Intermediate Certificate generation as you do not need to add attributes to the requests, or use the CA CLI Commands to produce the certificate (Although it is possible, the same as with OpenSSL to produce the necessary results)
As part of the installation of Microsoft CA, the root Certificate and Private Key is installed/imported into Certificate Services. The Root Certificate is used to generate Certificates on the CA.
Open the Blue Coat management GUI and select SSL->KeyRings Create a new Key Ring
KeyRing MicrosoftSSLDemo Select show-keypair
Create a new 2048 bit key Click OK
Click Apply
The Private Key has now been created on the Blue Coat SG.
Select the newly created “MicrosoftSSLDemo” Keypair and click “Edit/View” Under “Create Signing Request” click Create
Select the newly created “MicrosoftSSLDemo” Keypair and click “Edit/View” and copy the contents of the “Certificate Signing Request” to the clipboard.
Browse to the Certificate Server website http://certificateserver/certsrv
Select “Base 64 Encoded” file and click “Download Certificate”. Open the Certificate in Notepad, and copy the contents to your clipboard.
In the Blue Coat Management console, select the KeyRing and click Edit/View. Click Import under the Certificate section and paste the contents of the clipboard into the dialog box. Click Ok, Close, and then Apply.
The Intermediate Certificate is now installed. In the Blue Coat management console, select SSL->CA Certificates. Click Import and import the intermediate certificate into the CA chain. Paste the contents of the clipboard into the “CA Certificate PEM” Section, and give the Certificate a name
(“MicrosoftSSLInterceptIntermediate”).
Browse to http://certificateserver/certsrv/certcarc.asp and select the Certificate Authority. Select Base64 Encoding, and click “Download CA Certificate”. Open the certificate in Notepad, and copy the contents to the clipboard.
In the Blue Coat Management console, Import a new CA, and paste the contents of the clipboard into the “CA Certificate PEM” Section, and give the Certificate a name (“MicrosoftSSLInterceptRoot”)
Intercepting SSL
The next step in Intercepting SSL it to apply policy for interception.
This document does not intend to cover the policy around interception, however whether to intercept an SSL connection is entirely dependent upon policy, e.g. source, destination, issuer, etc, as well as whether the original certificate passes certain trust criteria.
If the deployment is an Explicit Proxy (i.e. the browser is configured to use a proxy server) then in the Blue Coat GUI, under proxy-services->HTTP select “detect-protocol”. This allows the Proxy SG to detect HTTPS being tunneled over an HTTP Proxy connection
If the deployment is transparent (either inline or via WCCP) then in the Blue Coat GUI, under proxy-services->HTTPS, enable interception of port 443.
For SGOS 5.3 and above only :-
In the Blue Coat GUI, under Proxy Settings->SSL Proxy select :- Issuer Keyring = Intermediate CA
CCL for Client Certificates = browser-trusted CCL for Client Certificates = browser-trusted
Under SSL->CA Certrificates->CA Certificates lists, edit Browser-trusted Add the Root Certificate, and Intermediate Certificates
In the Blue Coat GUI, select Policy->Visual Policy Manager, and click Launch
In the Visual Policy Manager, Select the Policy menu, and click “Add SSL Intercept Layer” Give the layer a name “SSL Intercept”
On the newly create SSL Intercept layer, select the action “none” and right click, select “Set” Click New, and select “Enable HTTPS Interception…” to create a new action
Tick the box for “Issuer Keyring” and select either the OpenSSLDemo or MicrosoftCADemo Keyring
Click OK
Highlight the EnableHTTPSInterception object and click OK
Click “Install Policy”
The selected KeyRing will be used for interception. Browsing to an SSL Website through the SG will cause a server certificate to be generated and presented to the client, with the certificate chain. Provided the Root CA is installed on the client, this will be fully transparent to the user. Clicking on the padlock in IE/Mozilla to view the certificate chain will show that instead of being signed by Verisign (for example) the certificate is signed by the Intermediate certificate which is trusted because the Intermediate certificate is signed by the trusted Root CA installed in the browser.
Secure ADN
Secure ADN uses intercepts at the branch. The Intermediate keypair is applied at each client site to allow for interception and acceleration. The traffic across the WAN between the core SG and the remote SG is encrypted using the device-authentication-profile, and the keypair associated with it. Therefore, for each deployed SG either a new intermediate Key Ring would be created, or a Key Ring would be replicated across all deployed SGs.
Appendix
Attached SG Configuration, Root Certificate, Root Private Key, Intermediate Certificate, and Intermediate Private Key. Router Configuration for completeness.
Root.pem Root.CER Intermediate.pem Intermediate.CER SGConfig.txt router.txt
Diagram :-
192.168.2.0/24 .254 .1 .10
