Decryption Log
Table of Contents
Decryption Log
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 the Proxy Type column).
Not all types of traffic support every parameter. Unsupported Parameters by Proxy Type and TLS Version provides
a complete list of unsupported parameters for each type of decryption
traffic.
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 incomplete is 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 ssl or
as incomplete.
To troubleshoot issues, use the Decryption ACC
widgets ()
to identify traffic that causes decryption issues and then use the
Decryption log and Custom Report Templates for Decryption to drill
down into details.
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.