About SSL Inspection

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 websites 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?  

How Zscaler Protects SSL Traffic

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

  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. To learn more, see:

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.

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

The Zscaler service supports TLS 1.0, 1.1, and 1.2. When SSL inspection is enabled, the service inspects all SSL/TLS sessions, regardless of version.

    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 the example image below). The browser receives this certificate signed by the Zscaler intermediate certificate along with the Zscaler intermediate certificate.
    See image.

    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. To learn more, see 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 Active Directory environments, you can use the AD's 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?
    See image.

    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 learn more about how Zscaler safeguards SSL keys and data collected during SSL inspection, see How does Zscaler safeguard SSL keys and data collected during SSL inspection?

    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 certificate signed by an organization's custom intermediate certificate.
    See image.

    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. If you do so, the certificate chain must be uploaded in the Zscaler 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.

    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. Because it enables 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.
    See image.

    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.
    See image.

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

    • Granular URL Filtering 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 Define your policy for SSL inspection.
    • Data Loss Prevention (DLP): The service can enforce the DLP policy only when SSL inspection is enabled.
       

      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.

    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 Filtering 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.

    There are some extra steps needed when dealing with remote users, or users from an unknown location. There are three ways to deal with these users. 

    TCP Port 9443

    Users can connect to ZENs on port 9443 and all HTTPS connections will be subject to SSL inspection. The drawback of this method is that the capability to bypass certain traffic based on URLs and URL categories from SSL scanning and authentication is lost.

    Users should also have the appropriate SSL certificate installed. If it is not installed and a user forwards traffic to port 9443, the browser will display certificate warnings.

    Dedicated Proxy Port

    If your organization has subscribed to a dedicated port and has getaway locations created using the dedicated port, your organization’s users may forward traffic to Zscaler on said port. 

    The decision of if the SSL traffic should be intercepted or not is something that can be defined by the location configuration. As the port is unique to the organization, it would be used as an identifier to apply your organization's SSL and Authentication bypasses. 

    However, if the first transaction from a user is from an unregistered IP and is an HTTPS request, the identity of the user is unknown and in order to accept the traffic the transaction needs to be authenticated. This is to ensure Zscaler is not used as an open proxy by unauthorized users.   

    If the organization has Show Notification enabled under Policy > SSL Inspection > Policy for SSL Decryption on the Admin Portal,  then the transaction is force intercepted and checked for a valid authentication cookie. If the cookie is not present, the user is redirected for authentication. After authentication, the traffic is accepted by Zscaler and appropriate policies applied. 

    The user would need to have appropriate root certificates installed on the user’s browsers to avoid certificate warnings.

    If the organization has Show Notification disabled, then the transaction is dropped. The user would need to access an HTTP page and provide a valid authentication cookie or go through the authentication process before accessing the HTTPS page. 

    Zscaler App

    The final, and recommended, option is to install and use the Zscaler App on the client machines of your remote users and activate the Enable SSL Scanning for Mobile Traffic option.

    TCP Port 80/443/9400/9480 

    Remote users may forward traffic to Zscaler on ports 80/443/9400 and 9480. However, there are a few issues to be aware of:

    • SSL traffic is not intercepted and policies are not implemented on SSL traffic.
    • If the first transaction from an unregistered IP address and is on HTTPS, the transaction is blocked. The user would need to access an HTTP page and provide a valid authentication cookie or go through the authentication process before accessing the HTTPS page. 
    • SSL and Authentication Bypass is not applied. 

    TCP Port 8800

    Remote users may use port 8800 to forward traffic to Zscaler and ZENs will attempt to authenticate the user using the Kerberos method of authentication. The organization may choose to decrypt HTTPS traffic by enabling Enable SSL scanning for Mobile traffic under Policy > SSL Inspection > Policy for Mobile Traffic.   

    Image of how Zscaler established a SSL tunnel between the browser and destination server

    Screenshot of Zscaler Intermediate Certificate for SSL Inspection

    Image of SSL inspection process when using Zscaler certificate

    Screenshot of certificate signed by custom intermediate certificate for Zscaler SSL inspection

    Image of Zscaler SSL inspection process when using custom certificate

    Screenshot of CRL distribution points provided by Zscaler

    Click Recommended Policy to view the policy Zscaler recommends.

    Screenshot of Recommended Policy icon for Zscaler SSL inspection

    To learn more, see How do I block HTTPS traffic without SSL inspection?

    To configure the service to globally block sites in predefined or custom URL categories:

    1. Go to Policy > Web > SSL Inspection.
    2. Under If SSL Inspection is Disabled, Block HTTPS to these Sites, configure the following:
    • Blocked URL Categories: Select URL categories for which you want HTTPS sites blocked. The HTTPS block applies globally to all configured locations. For the setting to apply to remote users, you must have a dedicated proxy port or the Zscaler App in use. You can select any number of categories and also search for URL categories.
    • Blocked URLs: Enter the URLs of the HTTPS websites you want blocked. The block applies globally to all configured locations. For the setting to apply to remote users, you must have a dedicated proxy port or the Zscaler App in use. To learn more, see URL format guidelines.
    • Show Notifications for Blocked Traffic: Turn this on to display notifications to users when HTTPS transactions are blocked. The Zscaler root certificate must be installed in users' browsers to display the notification. If the certificate is not installed, or if you do not enable this option, the browser only displays to the user a Page Not Found error when HTTPS sites are blocked.
    1. Click Save and activate the change.

    Defining your policy for SSL inspection is one of the tasks you must complete when deploying SSL inspection. To learn more, see How do I deploy SSL inspection? and What is the recommended SSL inspection policy?

    To define your organization's policy for SSL inspection:

    1. Go to Policy > Web > SSL Inspection.
    2. In the Policy for SSL Decryption section, configure the following:
    • Block Undecryptable Traffic: Enable this to block traffic from applications that use non-standard encryption methods and algorithms.
    • Do Not Inspect Sessions to these URL Categories: If you don't want the service to decrypt sessions to certain URL categories, specify them here. For the setting to apply to remote users, you must have a dedicated proxy port or the Zscaler App in use. You can select any number of categories and also search for URL categories.
    • Do Not Inspect Sessions to these Hosts: If you don't want the service to decrypt sessions to certain hosts, specify them here. For guidance on entering URLs, see URL format guidelines. For the setting to apply to remote users, you must have a dedicated proxy port or the Zscaler App in use.
    • Do Not Inspect these Applications: If you don't want the service to decrypt transactions to certain cloud apps or cloud app categories, specify them here. You can select any number of cloud apps and also search for cloud apps.
    • Untrusted Server Certificates: Select how the service handles certificates from untrusted issuers (if certificate issuer is unknown, or certificate has expired, or if Common Name in the certificate does not match).
      • Allow: The service allows access to sites with untrusted certificates. Certificate warnings are not displayed to users.
      • Pass Through: Certificate warnings are displayed to users, and they can decide to proceed to the site.
      • Block: The service blocks access to sites with untrusted certificates.
    • Block Site with Revoked Server Certificate: Enable to block access to sites with revoked certificates. The service uses the Online Certificate Status Protocol (OCSP) to obtain the revocation status of a certificate. When users are blocked, the service displays a notification and logs these transactions with 'bad server cert' in the policy field.
    1. In the Policy for Mobile Traffic section, select Enable SSL Scanning for Mobile Traffic to allow SSL inspection for roaming devices. This must be enabled if you want the service to perform SSL inspection for traffic sent to the service with the Zscaler App.
    2. Click Save and activate the change.

    Downloading a Zscaler certificate is one of the steps you must complete when configuring a Zscaler intermediate certificate. To learn more, see How do I use the Zscaler certificate for SSL inspection?

    To download the Zscaler certificate:

    1. Go to Policy > Web > SSL Inspection.
    2. In the Intermediate Root Certificate Authority for SSL Interception section, click Download Zscaler Root Certificate.