The Zscaler software architecture is engineered to minimize exposure of the private keys as well as the SSL intercepted data collected during SSL inspection. The keys and data are kept secure at all phases below:
When the administrator of an organization requests a CSR for an intermediate CA, the Zscaler Central Authority generates a 2048-bit private and public key pair. The private key is immediately encrypted with AES encryption using a password. The Central Authority uses a proprietary algorithm that leverages a security library developed by Zscaler to generate the private key password that it uses to encrypt the private key. When a ZEN requests the private key for SSL interception it uses this same algorithm to decrypt the private key, as explained in Key Distribution. This ensures that the private key password is not transmitted or stored on disk on any system; it is stored in the system’s memory only.
The Central Authority encrypts the private key and stores it in an SQL database that contains your organization’s policies. Any write operation to the Central Authority database is immediately replicated to two other identical Central Authority servers in physically separate locations in the US for rapid disaster recovery.
When a user from your organization tries to access a site that uses HTTPS/SSL, the ZEN requests your organization’s key pair from the Central Authority. The Central Authority sends the key pair over a 2048-bit TLS connection to the ZEN, along with your organization’s intermediate certificate. The Central Authority sends the key pair and certificate only to the requesting ZEN.
If a location’s traffic is sent to an organization’s private ZEN only, then the Central Authority sends the private key to the private ZENs only. It does not send the organization’s keys and intermediate certificate to public ZENs on the Zscaler cloud.
The CA never decrypts the private key. The private key is decrypted in a ZEN’s memory using the same proprietary algorithm and software library that the Central Authority used to encrypt the private key.
The ZEN maintains the private key unencrypted in its RAM in order to generate certificates for the websites that the user visits. These certificates are dynamically generated each time in RAM and not stored in any storage medium.
Additionally, the ZEN caches the intermediate certificate that it received from the Central Authority, until it receives a new intermediate certificate from the CA. Your organization sets the expiration date for the certificate and can revoke it at any time. Administrators cannot use the intermediate certificate issued to Zscaler to sign any other certificate because the private key never leaves the Zscaler Central Authority or ZEN.
If all Central Authority servers in a cluster are not available due to a catastrophic event and the ZENs are still active, the ZENs continue to perform SSL interception as long as an organization’s policies, certificates and keys already reside in the ZEN’s memory. If a ZEN does not have the policy and keys for an organization, then the ZEN will not decrypt the SSL traffic. In the unlikely event that both the CA and ZEN are not available, the Zscaler service supports a proxy bypass capability where all traffic will be allowed without protection.
A ZEN allocates memory from a special region for all SSL operations. This region of memory is always zeroed out as soon as the memory is released. This applies to packet buffers as well as key storage areas. A ZEN also does not allow a data dump from this area from the command line. All data is zeroed out if a process core must be dumped due to a software error.
The Central Authority sends SSL keys only to the ZENs that process your organization’s traffic. They are only ephemerally present in the ZEN RAM and are zeroed out of RAM after they are unused for a short period of time.
Once a new intermediate certificate is generated, a new key is generated as well. The old key and intermediate certificate are removed from the database as well as the database backup.
Zscaler operations processes and its ISMS (Information Security Management System) are ISO27001 certified. All ZENs and Central Authorities are monitored 24x7 and access to the Central Authority and ZENs is highly restricted and controlled.