Knowledge Base Article

Simplifying TLS Inspection with Cato's ML-driven Wizard

You made the first step, this is THE place to learn more, get your questions answered and share your experiences with other Cato customers.

Our TLS Wizard is designed with a clear purpose: intelligently determine which traffic to bypass and which to inspect, giving you immediate visibility into the most-commonly used applications and websites in your network. We leverage real-world customer traffic insights to identify which traffic works well with TLS inspection and which might be problematic.

What Traffic Should Not Be Inspected?

Four types of traffic should typically bypass TLS inspection:

  • Certificate Pinned Applications - These applications require specific certificates and will fail when inspected. Cato automatically bypasses known problematic OS, applications and URLs using our default bypass rule — without requiring the Wizard!
  • Embedded OS Devices - IoT devices like printers, cameras, and smart TVs don't support certificate installation and won't work with TLS inspection.
  • Sensitive Categories - While Cato never stores payload data, bypassing health, medical, and financial categories helps ensure privacy and compliance.
  • Traffic originating from Guest networks (or other devices that do not have the Cato certificate installed) – typically it’s not possible to inspect traffic from guest devices as they will not have the Cato certificate installed and will therefore generate an error if inspected.

The TLS Wizard adds bypass rules for embedded OS and sensitive categories automatically.  The bypass of guest networks will need to be created manually as this is not a generic rule that applies to all customers.

What Traffic Should Be Inspected?

The Wizard recommends inspecting these five categories:

  • General, Business Information, Computers and Technology categories
  • Popular cloud applications
  • Cato-recommended domains (approximately 6,000 domains verified to work with TLS inspection)
  • Malicious and suspicious categories
  • Uncategorized and undefined categories

Remember, these are suggestions that you can customise during setup.  You might want to start by testing with specific users or groups.

Best Practice for the Default Inspection rule

To prevent unexpected traffic inspection, we recommend configuring your default TLS inspection rule to bypass.

After running the Wizard, you'll be:

  • Bypassing known problematic sources and destinations
  • Inspecting known-good, high-value destinations
  • Bypassing everything else by default

You can customise and expand upon this foundation later, we recommend adding the bypass for the guest networks in the appropriate section of the TLS inspection policy as a starting point.

See the TLS Wizard in Action:

Have questions? Use the "comment" option at the bottom of this page. We're monitoring closely and ready to assist you on your journey

Updated 10 days ago
Version 2.0

1 Comment

  • DLyon's avatar
    DLyon
    Icon for Cato Employee rankCato Employee

    Working with a number of customers on this topic, I've been asked if the SafeTLS policy can be used to add rules to an existing TLS inspection policy and the answer is very much yes.  If you're a customer that has not started your TLS inspection journey, then the approach above will give you a great starting point to build on. 

    If however, you are a customer that's started with TLS inspection, but maybe your TLS inspection report is highlighting there is room for improvement, then why not run the TLS Wizard and add to what you already have in place?  Remember, you can always add source users or groups to the suggested rules if you want to test with a smaller subset of users first.

    Another tip I've used with customers is to analyse the Events section under the "home" tab to get a sense of the percentage of TLS transactions that are inspected (represented as a 1 below) and bypassed (represented as a 0 below).  You can also see the TLS rule names that are most commonly hit, which will highlight any potential rule ordering issues etc.