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?
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.
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.
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?
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.
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.
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:
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.
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.
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.
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.
Remote users may forward traffic to Zscaler on ports 80/443/9400 and 9480. However, there are a few issues to be aware of:
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.
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:
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:
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: