This article discusses how to configure and customize the TLS Inspection policy to meet the specific requirements of your network.
Today most network traffic is encrypted (TLS, HTTPS), which often minimizes the benefit of scanning traffic with IPS, Internet firewall, Application Control Policy, and Anti-Malware traffic. If the traffic contains malicious content, it is also encrypted and the Cato security engines can't inspect or scan it.
When you enable TLS Inspection for your account, Cato securely decrypts traffic that passes through a PoP and the Cato security engines inspect it for malware and scan downloaded files. If the content of the traffic is confirmed as safe, Cato then re-encrypts the traffic and forwards it to the destination. However, if the content contains actual or suspected malware, then the Cato security engines block the traffic.
You can choose to use the default Cato policy that inspects all traffic. You can also create specific TLS Inspection rules that define which traffic is inspected and which traffic bypasses TLS Inspection.
Note
Note: By default, TLS Inspection is bypassed for these operating systems:
-
Android (due to issues related to certificate pinning)
-
Linux
-
Unknown operating systems
Cato includes several applications in an implicit bypass rule that are automatically excluded from TLS Inspection. For a list of these applications, see below Default Bypass Rules.
Some minimal latency is expected at initial connection due to the TCP and TLS handshakes that occur before data can flow to the appropriate network or security engine in the PoP. This latency is up to 8 milliseconds per packet.
The TLS Inspection engine inspects connections sequentially, and checks to see if the connection matches a rule. The final rule in the rule base is a default implicit ANY - ANY Inspect rule - so if a connection does NOT match a rule, then it is automatically inspected.
You can review the default rule settings in the Default Rules section at the end of the rulebase. The rule settings can't be edited except for the Untrusted Server Certificate action. For more about the Untrusted Server Certificate action, see below Adding Rules to Customize the TLS Inspection Policy.
Rules that are at the top of the rule base have a higher priority because they are applied to connections before the rules lower down in the rule base. For example, if a connection matches on rule #2, the action for this rule is applied to the connection and the TLS Inspection engine stops applying the policy to this connection. This means that rules #3 and below aren't applied to the connection.
The TLS Inspection rules let you use an inspect or bypass action for the TLS traffic.
Use the Inspect action to define TLS Inspection rules that decrypt connections and let the relevant security engines inspect the traffic for malicious content.
Use the Bypass action to define the traffic that bypasses TLS Inspection rules. Bypassed traffic isn't decrypted for inspection by the Cato security engines. Remember that a bypass rule only excludes a connection that does NOT match an inspect rule higher in the rule base.
You can change the priority of a bypass rule so that it has a higher priority than an inspect rule.
Use the TLS Inspection Policy window to configure the TLS Inspection policy for all traffic in your account. You can choose to use the default policy that inspects all traffic, or add inspection and bypass rules to create a custom policy.
Working with Multiple Items
When there are multiple items in a Source, or a What field, such as two groups or categories, then there is an OR relationship between these items.
Installing the Cato Root Certificate on End-user Devices
The Cato root certificate must be installed as a trusted certificate on every device and computer that connects to the Cato Cloud. For more information about installing the Cato certificate, see Installing the Root Certificate for TLS Inspection.
-
The Cato certificate can't be installed on most embedded operating systems (OS), therefore many devices using embedded OS lose connectivity when TLS Inspection is enabled. For more about which OS Cato supports for TLS Inspection, see Best Practices for TLS Inspection.
QUIC and GQUIC are transport protocols developed by Google that don't operate over TCP connections, and traffic using these protocols can't be inspected by the TLS Inspection service. Therefore we recommend that accounts that enable TLS Inspection block QUIC and GQUIC traffic using Internet Firewall rules. The rules that block this traffic force the flow to only connect using protocols that can be inspected by the TLS Inspection service. If you allow traffic using the QUIC and GQUIC protocols, the flows can't be inspected and are unnecessarily blocked.
The first time you enable the TLS Inspection policy, rules to block QUIC and GQUIC traffic are automatically added to the Internet Firewall policy. If the Internet Firewall policy already blocks QUIC traffic so that it can be correctly inspected, then no new rules are added.
For more about QUIC and GQUIC traffic, see Internet and WAN Firewall Policies – Best Practices.
The default Cato TLS Inspection policy inspects all traffic (except for the applications that are automatically bypassed). You can use the default policy by enabling TLS Inspection and there is no need to add any rules to the policy.
There is a final implicit rule that matches all traffic with the Inspect action.
You can customize the TLS Inspection policy to only inspect the specific traffic types according to the needs of your organization. Add rules to the policy with Inspect and Bypass actions to define which traffic is decrypted and inspected.
-
Create rules with the Inspect action to define traffic that the Cato Cloud inspects for suspicious and malicious content.
-
Create rules with the Bypass action to exclude specific traffic from the Cato TLS inspection engines. For example, you can add a bypass rule for the RingCentral application to exclude RingCentral traffic from TLS Inspection.
When creating rules, use Source and What to define the scope of the TLS traffic and Action to configure whether the rule inspects or bypasses traffic. Make sure that the bypass rule has a higher priority (closer to the top of the rulebase) than an inspect rule that matches the same traffic. Traffic that matches a TLS Inspection bypass rule is also excluded from security scans by the Anti-Malware engines.
When you configure a rule with the Inspect action, you also must define the behavior for how the rule handles untrusted server certificates.
These are the options for this setting:
-
Allow - The traffic is allowed to the site with an untrusted certificate, and inspected (this is the default setting).
-
Prompt - The users are shown a prompt asking them to confirm that they want to continue and go to the site with an untrusted certificate. If the user continues to the site, the traffic is inspected
-
Block - Traffic to the site with an untrusted certificate is blocked
Note
Note: For applications that use certificate pinning to prevent TLS inspection, add them to a bypass rule so they will function correctly for the end users.
To add rules to the TLS inspection policy:
-
From the navigation menu, click Security > TLS Inspection.
-
Click New.
-
Enter a Name for the rule.
-
Use the Enabled toggle to enable or disable the rule.
The toggle is green when enabled.
-
Configure the Rule Order for this rule.
-
Expand Source and select the source type.
-
Select the type (for example: Host, Network Interface, IP, Any). The default value is Any.
-
When needed, select a specific object from the drop-down list for that type.
-
-
In the Device section, configure the Platforms, Countries, Device Posture Profiles , and Connection Origin required to match this rule.
For more about Device Conditions, see Adding Device Conditions for TLS Inspection.
-
Define What the rule applies to. For example, a service, an application, a custom or predefined category.
-
Configure the Action by selecting Inspect or Bypass.
-
If you select Inspect, from the Untrusted Server Certificates drop-down menu, select the action for traffic with problematic certificates: Allow, Block, or Prompt. The default value is Allow.
-
-
Click Apply.
-
Click Save. The TLS Inspection rule is saved in the rulebase.
This section explains how to manage the rules in the TLS Inspection policy, including: changing the rule priority, enabling, and deleting rules.
Change the priority of a rule to determine when the rule action is applied to a matching connection. Rules are applied sequentially to each connection, once a connection matches a rule, the rules with lower priority aren't applied to it.
Use the slider to enable and disable individual rules in the TLS Inspection policy.
Cato manages default TLS Inspection rules that bypass specific apps, operating systems, and clients that may cause issues. These rules are positioned at the top of the rulebase and can't be edited. To help you plan and make decisions for the TLS Inspection policy, you can view the settings for these rules in the Default Bypass Rules section.
Understanding TLS Inspection Event Fields
The following table describes event fields relevant for TLS Inspection:
Field Name |
Description |
---|---|
TLS Error Description |
Explanation of the TLS error in this event, values are: close notify, unexpected message, bad record mac, decompression failure, handshake failure, no certificate, bad certificate, unsupported certificate, certificate revoked, certificate expired, certificate unknown, illegal parameter, decryption failed, record overflow, unknown CA, access denied, decode error, decrypt error, export restriction, protocol version, insufficient security, internal error, user canceled, no renegotiation, unknown PSK identity, unknown For explanations of these errors, see this document |
TLS Error Type |
The type of TLS error related to this event, values are:
|
TLS Inspection |
Shows if traffic in the event was TLS. Values are 1 (inspected) and 0 (not inspected) The field appears only for TLS traffic flows |
TLS Version
|
TLS protocol version number for this event |
2 comments
Microsoft is in the process of shifting over to using the domain cloud.microsoft for their services - are the Cato catalogs being updated accordingly?
Ref https://learn.microsoft.com/en-us/microsoft-365/enterprise/cloud-microsoft-domain
Hi JM,
Yes, the Cato research team constantly monitors these types of changes, and it will be gradually deployed in the next few weeks.
Thanks for the question!
Jon
Please sign in to leave a comment.