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:
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.
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.
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.
Note: 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 example below). The browser receives this certificate signed by the Zscaler intermediate certificate along with the 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?
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 certificate signed by an organization's custom intermediate 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.
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.
Additionally, the Zscaler service provides the following benefits when an organization enables SSL inspection:
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.
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.
For more information, see How do I block HTTPS traffic without SSL inspection?
To configure the service to globally block sites in predefined or custom URL categories, follow the instructions below.
1. Go to Policy > Web > SSL Inspection.
2. Under If SSL Inspection is Disabled, Block HTTPS to these Sites, configure the following:
3. Click Save and activate the change.
NOTE: Defining your policy for SSL inspection is one of the tasks you must complete when deploying SSL inspection. See How do I deploy SSL inspection? for a full list of tasks.
To see the recommended policy for SSL inspection, see What is the recommended SSL inspection policy?
To define your organization's policy for SSL inspection, follow the instructions below.
1. Go to Policy > Web > SSL Inspection.
2. In the Policy for SSL Decryption section, configure the following:
3. In the Policy for Mobile Traffic section, configure the following:
4. Click Save and activate the change.
NOTE: Downloading a Zscaler certificate is one of the steps you must complete when configuring a Zscaler intermediate certificate. See How do I use the Zscaler certificate for SSL inspection? for the full list of steps.
To download the Zscaler certificate, follow the instructions below.