Decryption Logging & Monitoring

Log Overview

Effective decryption requires robust monitoring and logging to ensure it's working as expected, identify issues, and understand the security posture regarding encrypted traffic. Palo Alto Networks firewalls provide specific Decryption logs alongside other monitoring tools like the Application Command Center (ACC) for this purpose.

Key purposes and benefits of using Decryption logs include:

• Visibility: Gaining context about both successfully decrypted and undecrypted traffic flows.
• Troubleshooting: Diagnosing decryption failures by examining error messages, error indexes, and session parameters.
• Policy Verification: Confirming which Decryption policy rule matched a specific session.
• Security Posture Assessment: Identifying traffic using weak TLS versions or cipher suites.
• Compliance & Auditing: Providing records of decryption activity (though care must be taken with sensitive data).

By default, the firewall logs only unsuccessful TLS handshakes. Logging successful handshakes provides much greater visibility but significantly increases log volume and requires careful consideration of log storage capacity.

Decryption logs are NOT generated for:

• Traffic blocked during the SSL/TLS handshake (e.g., by URL Filtering or Security Policy before full decryption setup). Check URL Filtering logs instead.
• SSH Proxy traffic.
• Cleartext traffic (non-encrypted sessions).
• Traffic that does not match any Decryption policy rule.

Decryption Logging & Monitoring

Log Details & Fields

Decryption logs capture numerous parameters about the session and the TLS/SSL handshake process. Key fields often include:

• Session Information: Receive Time, Generate Time, Source/Destination IP, NAT IPs, Source/Destination Port, Protocol, Session ID, Rule Name/UUID, Virtual System.
• User Information: Source User, Destination User (if available via User-ID).
• Application Information: App-ID (if identified, see limitations below).
• TLS/SSL Details: TLS Version, Cipher Suite (Key Exchange, Encryption, Authentication algorithms), SNI (Server Name Identification), Certificate information (Issuer, Subject, Validity, Key Type, Key Size, etc.), Root CA status.
• Error Information: Error Index (categorizes failure reason), Error Message (specific description).
• Proxy Type: Indicates the decryption method used (e.g., Forward Proxy, Inbound Inspection, No Decrypt, Broker).

Unsupported Parameters

Not all log fields are populated for every type of decryption or TLS version due to protocol differences or where the information is available. For example:

• SNI & Root CA Info: Often unavailable for SSL Inbound Inspection or GlobalProtect portal/gateway sessions.
• TLSv1.3 Limitations: Certificate details and Negotiated EC Curve might be missing for 'No Decrypt' policies or certain proxy types because TLSv1.3 encrypts more of the handshake.
• Session Resumption: Certificate information is typically unavailable for resumed sessions.

Example Decryption Log View (Illustrative):

Decryption Logging & Monitoring

Log Configuration

Configuring decryption logging involves several steps:

1. Enable Logging in Decryption Policy Rules:
   • Navigate to Policies > Decryption .
   • Edit the specific rule(s) for which you want logs.
   • Go to the Actions tab (or Options tab in older versions).
   • Under Log Settings , you can choose to Log successful TLS handshakes in addition to the default logging of unsuccessful handshakes.
   • Logging successful handshakes significantly increases log volume.
   • To log traffic that is intentionally *not* decrypted (for visibility), use a "No Decrypt" action rule and ensure logging is enabled.
   
2. Configure Log Forwarding (Optional but Recommended):
   • If sending logs to an external system (Syslog server, SIEM, Cortex Data Lake, Panorama), create a Log Forwarding Profile.
   • Navigate to Objects > Log Forwarding and create a new profile.
   • Add a profile match list entry, select the Decryption log type, and configure the destination (e.g., Syslog server profile, Panorama/CDL).
   • You can add filters here to only forward specific types of decryption logs (e.g., only errors).
   • Apply this Log Forwarding Profile to your Decryption policy rules under the Actions/Options tab.
   • Ensure secure transport and storage for forwarded logs due to potentially sensitive content.
   • Specific formats like CEF or LEEF can be configured if required by the receiving system.
   
3. Adjust Log Storage Quotas:
   • If logging successful handshakes or a high volume of failures, you may need to increase the storage allocated to Decryption logs on the firewall or Panorama.
   • Navigate to Device > Setup > Management and edit Logging and Reporting Settings .
   • Under the Log Storage tab, adjust the Quota (%) for the Decryption log type.
   • The default quota is typically very small (e.g., 1%). Increase this by reducing quotas for other less critical log types, ensuring the total does not exceed 100%.
   • Consider factors like traffic volume, decryption rate, and retention needs when sizing quotas.
   
4. Set Log Expiration Periods:
   • Also under Log Storage settings, you can set the Max Days for how long decryption logs are kept before being automatically purged.
   • If the storage quota is reached before the expiration period, older logs will be purged regardless.

Decryption Logging & Monitoring

App-ID in Decryption Logs

The Decryption log attempts to populate the Application field using App-ID information learned from the corresponding Traffic log entry for the same session.

• Traffic Logging Dependency: To see App-IDs in Decryption logs, Traffic logging must be enabled on the Security Policy rule that ultimately allows the session. If Traffic logs are disabled for the matching Security rule, the App-ID in the Decryption log will show as incomplete .
• Timing Issues: For long-lived sessions, the firewall might generate the Decryption log entry (e.g., upon handshake completion or failure) before the full App-ID identification process is finished and the Traffic log is generated (often at session end). In such cases, the App-ID may appear as incomplete or simply ssl .
• Handshake Failures: When a TLS handshake fails, the session often terminates before the firewall can reliably identify the application beyond the base protocol (SSL/TLS). The App-ID will likely show as ssl or incomplete .
• Dropped Sessions: If the firewall drops the session early (e.g., due to policy or threat) before App-ID is finalized, the application may show as incomplete or unknown in associated logs.
• HTTP/2 Traffic: When decryption is enabled for HTTP/2, related logs might appear in the Tunnel Inspection log rather than the Traffic log. Tunnel Content Inspection needs to be enabled to get App-ID for this traffic.

Decryption Logging & Monitoring

Troubleshooting with Logs

Decryption logs are a primary tool for diagnosing decryption problems.

• Identify Failures: Filter logs based on Error Index (e.g., 'Certificate', 'Protocol', 'Cipher') or specific Error Message strings to isolate problematic sessions. Common failure reasons include certificate issues (untrusted issuer, expired, revoked, incomplete chain), unsupported TLS versions or cipher suites, client authentication requirements, or resource limitations.
• Verify Policy Match: Check the Rule field to confirm which Decryption Policy rule handled the session and whether the action was 'decrypt' or 'no-decrypt' as expected. Misconfiguration is a common cause of unexpected decryption behavior.
• Examine TLS Parameters: Review fields like TLS Version , Key Exchange , Encryption Algorithm , and certificate details to understand the nature of the connection and identify potential incompatibilities with Decryption Profile settings (e.g., blocking weak ciphers).
• Correlate with Other Logs: Cross-reference Session IDs between Decryption, Traffic, URL Filtering, and Threat logs to get a complete picture of how a session was handled, especially if it was blocked pre- or post-decryption attempt.
• Check Exclusions: If traffic isn't being decrypted as expected, verify it's not matching an entry in the global SSL Decryption Exclusion list or the Local Decryption Exclusion Cache ( Device > Certificate Management ).
• Use CLI Commands: Commands like show system setting ssl-decrypt certificate can verify certificate configurations , while session filters like show session all filter ssl-decrypt yes display active decrypted sessions .

Decryption Logging & Monitoring

ACC Widgets (PAN-OS 11.1+)

The Application Command Center (ACC), particularly the SSL Activity tab (introduced in PAN-OS 11.1), provides a high-level graphical overview of decryption trends and potential issues, complementing the detailed Decryption logs.

Key Widgets include:

• Traffic Activity: Compares overall SSL/TLS traffic volume/sessions against non-encrypted traffic.
• SSL/TLS Traffic: Breaks down encrypted traffic into successfully decrypted vs. undecrypted sessions/bytes. Helps identify large amounts of traffic bypassing decryption.
• Decryption Failure Reasons: Categorizes decryption failures (protocol, certificate, cipher, etc.) and allows drilling down by reason or by SNI to see which sites are causing the most issues.
• Successful TLS Version Activity: Shows the distribution of TLS protocol versions (e.g., TLSv1.2, TLSv1.3) used in successful handshakes, filterable by application or SNI. Useful for identifying reliance on older, weaker protocols.
• Successful Key Exchange Activity: Displays the key exchange algorithms used in successful handshakes, helping identify usage of non-PFS or weak algorithms.

Example: Drilling down in ACC

ACC Widget showing initial TLS Version distribution.

After clicking TLSv1.2, the widget shows SNIs using that version.

The ACC widgets allow interactive filtering and drill-down. Clicking on chart elements often refines the view, and a "Jump to Logs" icon typically allows pivoting directly to the filtered Decryption log view for detailed session analysis corresponding to the widget data.

Note: ACC widgets rely on identified applications (App-ID). If App-ID is incomplete or unknown in the logs (due to reasons mentioned previously), that traffic might not be accurately represented in application-specific widget views.

Knowledge Check: Decryption Logging & Monitoring

Test your understanding of the concepts.