How does Zscaler protect SSL traffic?

HTTPS is an aggregate of HTTP and the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocol, wherein the authentication and encryption capabilities of SSL/TLS protect HTTP communications. This is vital because the information that you send on the Internet is passed along from one device to another before it reaches the destination server. Therefore sensitive information, such as credit card numbers, usernames and passwords, may be seen by intermediate devices if the information is sent in clear text over HTTP. When the information is encrypted and protected by the SSL protocol, only the intended recipient can read the information. For more general information about SSL, see SSL 101.

Unfortunately, the security provided by SSL is also being misused in a number of ways:

  • SSL encryption is used to hide dangerous content such as viruses, spyware and other malware.
  • Attackers build their own web sites with SSL encryption.
  • Attackers inject their malicious content into well-known and trusted SSL-enabled sites.
  • SSL can be used to hide data leakage; for example, the transmission of sensitive financial documents from an organization.
  • SSL can be used to hide the browsing of websites that belong to legal-liability classes.

As more and more websites use HTTPS, including social media such as Facebook and Twitter, the ability to control and inspect traffic to and from these sites has become an important piece of the security posture of an organization.

The Zscaler service provides two options to protect your organization’s HTTPS traffic: SSL inspection, or if SSL inspection is not feasible for your organization, you can configure a global block of specific HTTPS content. See below to learn more about SSL inspection. To learn more about globally blocking specific HTTPS content, see How do I block HTTPS traffic without SSL inspection?  

 

Zscaler SSL Inspection

When you enable SSL interception, the Zscaler service establishes a separate SSL tunnel with the user’s browser and with the destination server. See below for an illustration of the process, followed by an explanation.

Zscaler SSL Inspection
  1. A user opens a browser and sends an HTTP request.
  2. The Zscaler service intercepts the HTTPS request, and through a separate SSL tunnel, sends its own HTTPS request to the destination server and conducts SSL negotiations. The destination server sends the service its certificate with its public key, and the Zscaler service and destination server complete the SSL handshake. The application data and subsequent messages are sent through the SSL tunnel.
  3. The Zscaler service conducts SSL negotiations with the user’s browser using either the Zscaler intermediate certificate, or your organization’s custom intermediate root certificate. See below for more background on each option.

SSL Inspection Using a Zscaler Intermediate Certificate

With this option, the service dynamically generates and signs the server certificate that it presents to the client. This certificate contains the same fields as the original destination server certificate, except for the identifying information of the issuer, called the issuer distinguished name (DN). The issuer DN is set to the name of the Zscaler intermediate certificate (see example below). The browser receives this certificate signed by the Zscaler intermediate certificate along with the Zscaler intermediate certificate.

SSL Inspection Using a Zscaler Intermediate Certificate

To enable your browser or system to automatically trust all certificates signed by the Zscaler Certificate Authority, your users must install the Zscaler Root CA certificate on their workstations (instructions for this step are provided in How do I deploy SSL inspection?). Otherwise, they will receive an error stating that there is a problem with the website’s security certification. In Microsoft AD environments, you can use the Active Directory GPO feature to facilitate installing the certificate on multiple computers. Your organization does not need to install the Zscaler intermediate certificate because the Zscaler service sends it together with the certificate the service generated for the destination site.

Below is an illustration that provides an overview of the Zscaler SSL inspection process when you configure the Zscaler certificate to establish an SSL tunnel with the browser. To learn how to configure the Zscaler certificate for SSL inspection, see How do I deploy SSL inspection?

SSL Inspection Using a Custom Intermediate Root Certificate

You can subscribe to the Custom Certificate feature and configure a custom intermediate root certificate for SSL inspection. When you do, the Zscaler service does not use your organization’s root certificate or private keys. Instead, it uses the custom intermediate root certificate signed by your own CA, so you can use a trusted CA that is already deployed on your organization's machines.

To configure an intermediate root certificate, you can generate a CSR (Certificate Signing Request) in the admin portal. The service generates the CSR with a key pair (public and private key) and encrypts the private key using AES. The private key is stored securely in the Zscaler Central Authority, while the CSR contains the public key. (To read more about how Zscaler safeguards SSL keys and data collected during SSL inspection, click here.)  After your CA signs the CSR, you can upload the signed certificate to the service. During the SSL negotiation with the user’s browser, the Zscaler service dynamically generates and signs the server certificate that it presents to the client with this intermediate certificate. The certificate issuer is set to the organization name, and the Zscaler service generates the certificate once per site and caches these certificates on the ZEN. These cached certificates are usually valid until their expiration date. Below is an example of a certificated signed by an organization's custom intermediate certificate.

SSL Inspection Using a Custom Intermediate Root Certificate

Uploading the Certificate Chain

In addition to the intermediate root certificate, you can upload the certificate chain that includes any other intermediate certificates that complete the chain to the intermediate root certificate you upload. (Note that if you do so, the certificate chain must be uploaded in the admin portal before you upload the intermediate root certificate so that the Zscaler service can validate the certificate against the chain.) When you upload the certificate chain, the Zscaler service sends the intermediate root certificate along with this key chain and the signed server certificate to your users’ machines during SSL inspection. If you do not upload the certificate chain, the Zscaler service sends only your organization’s intermediate root certificate and its signed server certificate to the user’s machine.

Uploading the certificate chain provides important benefits. The certificate chain ensures that your users’ machines can validate the server certificate signed by your organization’s intermediate CA even if the users’ browsers have only the root certificate in their certificate store. Furthermore, if you change your certificate due to the compromise of an intermediate root certificate, or simply as a routine security measure, the ability to send the certificate chain to users’ machines during SSL inspection is a key benefit, enabling you to rotate certificates efficiently without the need for a new key ceremony or certificate push to your organization’s users.  

Below is an illustration that provides an overview of the Zscaler SSL inspection process when you configure a custom intermediate root certificate signed by your organization’s CA to establish an SSL tunnel with the browser.

CDP for All Certificates

The Zscaler service provides a CRL (Certificate Revocation List) distribution point (CDP) for every certificate it generates, so that client applications can locate the Certificate Revocation Lists (CRLs) as necessary. The certificate displays the CDP, as shown in the image below. The CRLs are hosted by the Zscaler service and provide the serial numbers of revoked certificate issuers.

CDP for All Certificates

Additionally, the Zscaler service provides the following benefits when an organization enables SSL inspection:

  • Granular URL and Cloud App Control Policies: The service can enforce granular user, group and location policies that not only control access to sites or applications, but also control what a user can do within an application. For example, you can define a webmail policy that allows users to view and send mail, but not attachments; or a social media policy that allows users to view Facebook, but not post.
  • Skipping Inspection for Specific URLs/URL categories: When configuring SSL inspection policy, you can prevent the service from inspecting sessions to certain URLs or URL categories (for example, in the Banking and Healthcare URL categories). This list applies globally through an organization.  
  • Skipping Inspection for Specific Cloud Applications/Cloud Application Categories: When configuring SSL inspection policy, you can prevent the service from inspecting transactions to specific cloud applications or cloud application categories. This list applies globally through an organization.
  • Content Filtering: You can configure the service to enforce SafeSearch, enabling it to block malicious or inappropriate content in a page, such as during a Google search.
  • Block Undecryptable Transactions: You can enable the service to block the transactions of applications that the service cannot decrypt because they use non-standard encryption methods and algorithms
  • Block Advanced Persistent Threats (APT): 56% of targeted malware is delivered over SSL.
  • Control access to Google consumer apps and non-corporate Google accounts. See How do I control access to Google consumer apps?
  • Block access to sites with revoked certificates: The service supports OCSP (Online Certificate Status Protocol) to verify the validity of all server certificates. It verifies the OCSP responder URL in a server's certificate and sends an OCSP request to the responder. The service allows access if the responder indicates that the certificate is Good, and blocks access if the responder responds that the certificate is Unknown or Revoked. The service displays a notification when it blocks access to a site due to a bad certificate (if the certificate issuer is unknown, or if the certificate has expired, or if the Common Name in certificate does not match). It also logs these transactions with “bad server cert” in the policy field. To learn how you can specify the way the service handles certificates from untrusted issuers, see E. Define your organization's policy for SSL inspection in How do I deploy SSL inspection?
  • Data Loss Prevention (DLP): The service can enforce the DLP policy only when SSL inspection is enabled.

    NOTE: A ZEN is not a caching proxy. Data is inspected in a ZEN’s memory after decryption and sent out to the client immediately. Even when a core dump is taken on a ZEN, SSL session data is cleared before the dump file is created. SSL session data is never written to disk.

Deployment Scenarios for SSL Inspection

Zscaler's SSL inspection can be deployed in different scenarios. Click on the following scenarios to see how the service applies SSL inspection based on traffic source, and whether authentication or other features are enabled.

  • HTTPS Traffic from Known Locations

    When an organization’s traffic is forwarded from a known location (an Internet gateway configured in the Zscaler service portal), the Zscaler service applies URL and Cloud App control policies as described below, depending on whether user authentication is enabled.
    • Authentication Enabled: Zscaler recommends this configuration because it enables the service to enforce granular URL and Cloud App Control policies at the user level.
    • Authentication Disabled: The service applies location-based URL and Cloud App Control policies. It cannot apply any user or group policies because authentication is disabled. Ensure that the appropriate location is specified in the Location setting of the URL and Cloud App Control policies.
  • HTTPS Traffic from Road Warriors

    Road warriors or roaming users who use PAC files or who explicitly set their browsers to send traffic to the service from outside known locations can forward their traffic to port 9443 or to a dedicated proxy port.
    • Traffic is Forwarded to Port 9443
    • The service applies user and group URL and Cloud App Control policies.
    • Forwarding traffic to port 9443 enforces SSL decryption. Ensure that users have the appropriate SSL certificate installed if they forward their traffic to port 9443. If the SSL certificate is not installed and a user forwards traffic to port 9443, the browser displays certificate warnings.
    • Note that the option to bypass SSL inspection for specified URLs and URL categories is not supported in this deployment unless you are using the Dedicated Proxy Ports feature.
    • Traffic is Forwarded to a Dedicated Proxy Port
    • An organization can subscribe to one or more ports and associate them with a location.
    • When road warriors forward their traffic to a dedicated port that is associated with a location, the service associates all user traffic sent over the dedicated port with the location. The service applies location-based URL and Cloud App Control policies to the traffic of the road warriors. Ensure that the appropriate location is specified in the Location setting of the URL and Cloud App Control policies.

Note that whether you protect HTTPS traffic by deploying SSL inspection or by by blocking specific HTTPS traffic, the Zscaler service must first identify the host in an HTTPS request through an explicit or transparent proxy mode.