HTTPS connections are used to encrypt traffic used for most websites to ensure confidentiality. HTTPS can contain malicious content such as malware/viruses and other threats. The Cisco WSA supports HTTPS decryption, which allows the appliance to view the contents and inspect the traffic.

When using HTTPS decryption on a WSA, there are two different HTTPS connections, one between the user and the WSA and another between the WSA and the web server. The WSA performs the SSL handshake twice. The handshake between the user and the WSA, the WSA sends the client its own certificate, spoofing the requested web server certificate.

The diagram below represents the traffic flow between a client and a HTTPS server that goes through the WSA.

WSA Configuration

This section covers the steps required to configure and verify HTTPS decryption on the WSA, it is assumed the basic configuration of the WSA is already setup, refer to the following guides for initial setup and configuration.

To configure HTTPS Decryption on the WSA, the following must be configured:

• HTTPS Proxy
  
• Decryption Policy
  

HTTPS Proxy Configuration

The WSA uses a HTTPS Proxy to define the certificate, decryption options, invalid certificate handling (expired, mismatched hostnames etc), OCSP checks.

• Navigate to Security Services > Proxy Settings > HTTPS Proxy
  
• Click on Enable and Edit Settings
  
• Read and Accept the HTTPS Proxy License Agreement
  
• Under the section Root Certificate for Signing select Use Generated Certificate and Key
  
• Click Generate New Certificate and Key
  

• Click Generate
  

Once generated the page will display a link to download 2 files. The link Download Certificate… is a self-signed certificate, which could be imported to all computers. Alternatively, the link Download Certificate Signing Request is a CSR which can be signed by an Internal CA, such as a Microsoft Windows CA that is already trusted by AD domain joined computers.

In this example we will demonstrate using a certificate signed by an Internal Windows CA.

• Click Download Certificate Signing Request
  
• Open the HTTPS_csr.pem file in notepad and copy the contents
  
• Open a web browser and navigate to the Windows Certificate Portal – https://servername/certsrv
  
• Click Request a certificate
  

• Click advanced certificate request
  
• In the Saved Request box paste the contents of the CSR created in the previous steps.
  
• From the Certificate Template drop-down list, select Subordinate Certificate Authority
  

NOTE – It is important to select the Subordinate Certificate Authority certificate template, this certificate is used by the WSA to re-sign certificates dynamically, to spoof the destination web server certificate. An ordinary User or Web Server certificate etc, cannot be used for this purpose. A Public CA such as VeriSign, GoDaddy etc will not provide a Subordinate Certificate Authority template, only the self-signed WSA certificate or a certificate signed by a trusted Internal CA can be used.

• Click Submit
  
• Select Base 64 encoded
  
• Click Download certificate
  

• Return to the WSA Web GUI, navigate to Security Services > Proxy Settings > HTTPS Proxy
  
• Under the Signed Certificate section, click Browse and select the signed certificate.
  
• Click Upload
  

• Under the Decryption Options section, ensure Decrypt for End-User Notification is selected.
  

This option ensures decrypts traffic that should be blocked AND allows for an End-User notification web page to be displayed informing the users the connection is blocked. Dropping the traffic without decrypting would result in an error on the web browser, rather than a useful notification. Alternatively, the web site could be decrypted in the HTTPS Policy and blocked in the Access Policy (post decryption), though this is more expensive in terms of CPU cycles and overhead.

• Click Submit
  
• Click Commit Changes
  

Decryption Policy

With the HTTPS Proxy enabled, the WSA uses Decryption Policies to identify criteria to be matched, such as Identification Profile (authenticated against AD/LDAP) and advanced options such as Proxy Ports, Subnets, Time Range, URL Categories or User Agent. The WSA uses both URL Filtering and/or Web Reputation Score (WBRS) to make intelligent decisions about when to decrypt HTTPS connections. Web reputation filters assigns a WBRS to a URL to determine the likelihood that it contains URL based malware. The WSA uses WBRS to identify and stop malware attacks before they occur. Alternatively using URL Filtering based on URL Categories, such as Gambling, Social Networking etc.

The WSA can perform the following actions on an HTTPS connection request

• Monitor – the WSA continues evaluating the transaction against other control settings to determine which final action to apply.
  
• Drop – the WSA drops the connection and does not pass the connection request to the server. The WSA does not notify the user that the connection was dropped.
  
• Pass through – the WSA passes through the connection between the client and server without inspecting the traffic content. The WSA does check the validity of the requested server by initiating an HTTPS handshake. The requested server certificate is validated, if the check fails the connection is blocked. Validation checks can be skipped for specific sites.
  
• Decrypt – the WSA allows the connection but inspects the traffic content. It decrypts the traffic and applies Access Policies to decrypted traffic as if it were plaintext HTTP connection, this allows for Malware scanning.
  

NOTE – all actions are final, except Monitor. A final action is an action that causes the WSA to stop evaluating the transaction against other rules.

• Navigate to Web Security Manager > Web Policies > Decryption Policies
• Click Add Policy…
• Define an appropriate name, i.e., HTTPS Policy
• Select the Identification Profile to authenticate the users (if required).
• Optionally click Advanced

• Click Submit
  
• Click (global policy) under the URL Filtering column for the HTTPS Policy.
  

As default all Categories will be inheriting the Global Settings, which is to Monitor.

• For the Lotteries category, select the action Decrypt
  

• For Social Networking, select the action Drop
  
• Click Submit
  

The Decryption Policy should confirm Decrypt 1, Drop 1 and the rest as Monitor.

• Click Commit Changes
  

Testing

For testing we shall browse to a Lottery website and confirm the site has been decrypted.

• From a web browser, go to any lottery website, i.e., the National Lottery.
  
• The web site should load, click the pad lock at the URL bar at the top of the web browser and browse the certificate.
  

From the output below, observe the Common Name of Issuer is WSA LAB, as we configured during setup, this certificate was signed by the Internal CA called lab-PKI-CA. This confirms the WSA decrypted the website which is classified in the URL Category “Lotteries”, re-signing using its own certificate.

Browsing to any other website, other than a lottery site or social networking site should present the real certificate, confirming traffic was not decrypted by the WSA.

From a web browser open a social networking site, such as Instagram.com, this should result in a block message being displayed.

• From the CLI of the WSA run the command tail
  
• Select option 1 (accesslogs)
  
• Generate some web traffic to Instagram.com
  

From the output below we can confirm https://www.instagram.com matched the HTTPS Policy and decrypted which is followed by the connection being dropped by same policy.

• From the GUI navigate to Reporting > Web Tracking
  
• Filter on the IP address of the client computer
  

From the output below we can confirm the connections to Instagram.com were blocked and which decryption policy blocked the connection.

Summary

The following is list of important basics of HTTPS decryption

• HTTPS Proxy is required if using Transparent Proxy (WCCP)
  
• The certificate used by the WSA must be a Subordinate Certificate Authority certificate.
  
• The client computers must trust the Certificate Authority that issued the certificate to the WSA, to ensure no certificate errors.
  
• If dropping traffic in the Decryption policy, ensure Decrypt for End-User Notification option is selected, for the users to receive a block page.
  
• If dropping traffic in the Access Policy, decrypt the traffic in the Decryption Policy. Be aware this is more CPU intensive as it requires more processing.
  

References

Cisco reference documentation

https://www.cisco.com/c/en/us/td/docs/security/wsa/wsa11-0/user_guide/b_WSA_UserGuide/b_WSA_UserGuide_chapter_01110.pdf