• How TLS decryption works
• Impact on your applications and network
  • Some applications stop connecting
  • Services that allowlist your IP addresses refuse traffic
  • Firewalls with their own TLS inspection
• Turn on TLS decryption

Most internet traffic is encrypted with Transport Layer Security (TLS). As a consequence, only the device and the site can read the contents of a TLS connection. Without TLS decryption, Internet Threat Protection (ITP) in Cloud Secure Edge (CSE) sees only the domain a user connects to, such as example.com. It does not see the full URL that the user visits, the files the user downloads, or the account with which the user signs in.

TLS decryption lets ITP see inside that traffic and stop threats that a domain check cannot catch. A trusted domain can still host a malicious URL or serve a file that contains malware. A user can also sign in to an AI app with a personal account instead of a company one. Your contract with the AI provider covers company accounts only. Company data that the user pastes into a personal account falls outside your admin controls, and the provider may use it to train its models.

How TLS decryption works

Without decryption, ITP only checks domains. Before a device connects to a site, the desktop app sends the site’s domain to ITP and asks whether to allow it. ITP replies with allow or block. If ITP allows the domain, the device connects to the site directly. The traffic itself never reaches CSE. For more detail, see ITP Architecture.

With decryption on, traffic that matches the ITP policy goes to the CSE Secure Web Gateway (SWG) before it reaches the site. The SWG runs in the CSE data center nearest to the user. It decrypts the traffic, inspects it, and re-encrypts it with a certificate from the CSE certificate authority (CA). It then sends the traffic on to the site. Replies from the site come back through the SWG too.

Because ITP now sees each full URL, the Internet Access Logs record the full URL of each request, such as example.com/downloads/setup.exe, instead of only the domain. To download these logs, go to Logs > Access Logs in the Command Center. See Access Logs.

Impact on your applications and network

Turning on decryption can stop some applications and services from working. Check for these three cases before you turn it on for a group of users.

Some applications stop connecting

With decryption on, devices receive a certificate from the CSE CA instead of the site’s own certificate. Most applications accept it, but some refuse to connect.

The desktop app installs the CSE CA certificates in the operating system certificate store. Browsers and most applications trust the certificates in that store, so they keep working without any action from you. To check that the SWG is inspecting a site, open the site’s certificate details in the browser. The certificate chain includes the CSE CA.

These three kinds of application reject the CSE certificate:

• Applications that pin certificates. The application compares the site’s certificate with a copy that is built into the application. The certificate from the CSE CA does not match, so the application cannot connect.
• Applications with their own list of trusted CAs. The application ignores the operating system certificate store and uses a list that ships with it. Many developer tools and runtimes work this way.
• Applications that use mutual TLS. The application proves its identity with a client certificate. It cannot present that certificate through a decrypted connection.

You can recognize this problem by three signs:

• A desktop application cannot connect or sign in.
• The same service works in a browser on the same device.
• The application works again when you turn decryption off.

To fix it, do one of these:

• Add the CSE CA certificates to the application’s own trust settings, usually through your mobile device management (MDM) system. See SWG CA Certificates for Certificate-Pinned Apps.
• Check whether the application’s domains are already in Global TLS Decryption Exclusions. SonicWall maintains this list for every org, and the SWG does not decrypt traffic to the domains on it.
• In the ITP policy, add the application’s domains to Domain and URL Bypass as domain entries.

Warning: ITP does not inspect or log traffic to a bypassed domain. Keep each bypass entry as narrow as the application allows.

Services that allowlist your IP addresses refuse traffic

With decryption on, services that only accept traffic from IP addresses you list in advance refuse your users’ traffic. Examples include SaaS applications, partner APIs, and firewall rules on your own network that allow only your office or VPN addresses.

This happens because the service no longer sees the user’s public IP address. It sees the IP address of the CSE data center where the SWG handled the connection, and that address is not on the allowlist.

Find these allowlists before you turn on decryption for a group of users. If you skip this step, the first sign of the problem is users who cannot reach the service.

For each of these services, do one of these:

• Route the traffic through a Service Tunnel. The traffic then leaves from one fixed IP address, which you add to the allowlist once. That address belongs to the CSE-hosted Global Edge or to a Private Edge that you host. ITP does not evaluate traffic in a Service Tunnel, so the service loses ITP inspection.
• Add the service’s domains to Domain and URL Bypass. The traffic then goes straight from the device to the service. The bypass warning applies.

Firewalls with their own TLS inspection

Some networks run TLS inspection on a firewall, such as SonicWall Deep Packet Inspection of SSL (DPI-SSL). The firewall can also decrypt the connection between the desktop app and the SWG. The traffic is then decrypted twice, once by the firewall and once by the SWG.

This happens because the desktop app does not pin certificates. It accepts any certificate that chains to a CA in the operating system certificate store. A firewall that inspects TLS presents its own certificate, and organizations that use one usually install the firewall’s CA on their devices. On those devices, the desktop app accepts the firewall’s certificate.

To keep the firewall out of the connection between the desktop app and the SWG, exclude this domain from TLS inspection on the firewall:

*.swg.banyanops.com

Turn on TLS decryption

The Enable Advanced Configurations toggle turns on TLS decryption for one ITP policy. The toggle is in the Assignment step of the ITP policy. See Manage ITP Policies.

These features only work when the toggle is on:

• URL entries in Domain and URL Blocking and Bypass. ITP can block or bypass a full URL, such as example.com/downloads. Domain entries work either way. With the toggle off, URL entries stay on the policy, but ITP does not enforce them.
• Risk-based URL Filtering. ITP checks each full URL for threats and blocks the risky ones. With the toggle off, this feature is unavailable.
• File Analysis in Malware Download Protection. ITP scans downloaded files for malware and blocks malicious files before they reach the device. With the toggle off, File Analysis turns off, and the console shows a warning.
• Require Approved Accounts for AI Apps. ITP reads the account a user signs in with and blocks AI prompts from accounts outside your approved email domains. With the toggle off, the console hides this setting.

If you turn the toggle back on, ITP enforces the URL entries and File Analysis again without any reconfiguration.

Turn on decryption for a pilot group before the whole org, so you find affected applications and allowlists early. Roll Out ITP in Your Org has the steps.