The Decryption Log (
) provides comprehensive information about sessions that match a Decryption policy to help you gain context about that traffic so you can accurately and easily diagnose and resolve decryption issues. The firewall does not log traffic if the traffic does not match a Decryption policy. If you want to log traffic that you don’t decrypt, create a policy-based decryption exclusion and for policies that govern TLSv1.2 and earlier traffic, apply a No Decryption profile to the traffic.
PAN-OS supports Decryption logs for the following types of traffic:
- Forward Proxy—Several fields only display information for Forward Proxy traffic, including Root CA (for trusted certificates only) and Server Name Identification (SNI).
- Inbound Inspection.
- No Decrypt (traffic excluded from decryption by Decryption policy).Because the session remains encrypted, the firewall displays less information. For undecrypted TLSv1.3 traffic, there is no certificate information because TLSv1.3 encrypts certificate information.
- GlobalProtect—Covers GlobalProtect Gateway, GlobalProtect Portal, and GlobalProtect Clientless VPN (client-to-firewall only).GlobalProtect does not support TLSv1.3.
- Decryption Mirror
- Decryption Broker (shown as Forward Proxy in theProxy Typecolumn).
The data for Forward Proxy traffic is based on whether the TLS handshake is successful or unsuccessful. For unsuccessful TLS handshakes, the firewall sends error data for the leg of the transaction that caused the error, either client-to-firewall or firewall-to-server. For successful TLS handshakes, the data is from the leg that successfully completes first, which is usually client-to-firewall.
Decryption logs are not supported for SSH Proxy traffic. In addition, certificate information is not available for session resumption logs.
By default, the firewall logs all unsuccessful TLS handshake traffic. You can also log successful TLS handshake traffic if you choose to do so. You can view up to 62 columns of log information such as application, SNI, Decryption Policy Name, error index, TLS version, key exchange version, encryption algorithm, certificate key types, and many other characteristics:
Click the magnifying glass icon ( ) to see the Detailed Log View of a session.
The Decryption log learns each session’s App-ID from the Traffic log, so Traffic logs must be enabled to see the App-ID in the Decryption log. If Traffic logs are disabled, the App-ID shows as
incomplete. For example, a lot of GlobalProtect traffic is intrazone traffic (Untrust zone to Untrust zone), but the default intra-zone policy does not enable Traffic logs. To see the App-ID for GlobalProtect intrazone traffic, you need to enable the Traffic log for intrazone traffic.
Another reason that the App-ID may display as
incompleteis that for long sessions, the firewall may generate the Decryption log before the Traffic log is complete (the Traffic log is usually generated at session end). In those cases, the App-ID is not available for the Decryption log. In addition, when the TLS handshake fails and generates an error log, the App-ID is not available because the failure terminates the session before the firewall can determine the App-ID. In these cases, the application may display as
When you forward Decryption logs for storage, ensure that you properly secure log transport and storage because Decryption logs contain sensitive information.
When the Decryption logs are enabled, the firewall sends HTTP/2 logs as Tunnel Inspection logs (when Decryption logs are disabled, HTTP/2 logs are sent as Traffic logs), so you need to check the Tunnel Inspection logs instead of the Traffic logs for HTTP/2 events. In addition, you must enable Tunnel Content Inspection to obtain the App-ID for HTTP/2 traffic.
Recommended For You
Recommended videos not found.