TLS/SSL Rule Conditions

A TLS/SSL rule’s conditions identify the type of encrypted traffic the rule handles. Conditions can be simple or complex, and you can specify more than one condition type per rule. Only if traffic meets all the conditions in a rule does the rule apply to the traffic.

If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based on the server certificate used to negotiate the session, regardless of the session SSL or TLS version.

Every TLS/SSL rule has an associated action that determines the following for matching encrypted traffic:

  • Handling: Most importantly, the rule action governs whether the system will monitor, trust, block, or decrypt encrypted traffic that matches the rule’s conditions

  • Logging: The rule action determines when and how you can log details about matching encrypted traffic.

Your TLS/SSL inspection configuration handles, inspects, and logs decrypted traffic:

  • The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt.

  • The policy’s default action handles traffic that does not meet the condition of any non-Monitor TLS/SSL rule.

You can log a connection event when the system blocks or trusts an encrypted session. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events, however:

  • For blocked connections (Block, Block with reset), the system immediately ends the sessions and generates an event

  • For Do Not Decrypt connections, the system generates an event when the session ends

Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.

Caution

Adding the first or removing the last active authentication rule when TLS/SSL decryption is disabled (that is, when the access control policy does not include an SSL policy) restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort Restart Traffic Behavior for more information.

Note that an active authentication rule has either an Active Authentication rule action, or a Passive Authentication rule action with Use active authentication if passive or VPN identity cannot be established selected. In each case the system transparently enables or disables SSL decryption, which restarts the Snort process.

Caution
When TLS/SSL decryption is disabled (that is, when the access control policy does not include an SSL policy), adding the first or removing the last captive portal rule restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort Restart Traffic Behavior for more information. A captive portal rule either has an Active Authentication rule action or has TBD selected when the rule action is Passive Authentication.