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:- Becomes signed by the Certificate Chain on the Blue Coat SG.
The following process describes the SSL Session creation between client, SG, and Webserver. The key to full transparency is to ensure that the certificate and the certificate chain used by the SG is trusted by the client, and sent during the certificate exchange.
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 Create the CA: 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. # 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 At this stage a Certificate Authority has been created. The choice now is to either generate a certificate signing request (CSR) on the SG or create an intermediate CA via SSL and import into the SG.
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/ mv ca2008.crt cacert.pem
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 -----END CERTIFICATE----- (Inclusive) to the clipboard. Now, select the new KeyPair, and click Edit/View. Select Import from the Certificate portion of the window and paste the contents into here.
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. Setting up a Certificate Authority with Microsoft Certificate Server Setting up the Root CA and Intermediate CA with OpenSSL allows for an approximation of the configuration desired for integration with an enterprise Active Directory. The following describes how to use Microsoft
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 Fill in the details for the Intermediate Certificate and click OK, then Close, and then Apply.
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 Click on Advanced Certificate Request, and then Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.. The URL should now be http://certificateserver/certsrv/certrqxt.asp. Paste the contents of the clipboard into the Saved Request field, and from the certificate template menu, select Subordinate Certification Authority. Click Submit.
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 At this points, the Intermediate Private Key and Certificate are installed on the SG and the root certificate is installed for the certificate chain. The Root Certificates should be installed into the Trusted Root Certification Authorities on the client PCs. This is to replicate the workstations being part of an Active Directory where this trust is implied.
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 Click OK
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. Browsing to https://www.play.com, with the OpenSSLIntermediateCA keychain applied generates the following:-
Clicking on the padlock and selecting view certificates, and then Certification Path :-
Using the Microsoft CA Certificate, the following occurs browsing to https://www.americanexpress.com generates the following :-
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.1.0/24.254.1 192.168.2.0/24.254.1.10