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
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.
The firewall does not generate Decryption log entries for
web traffic blocked during
SSL/TLS handshakes. These
sessions do not appear in Decryption logs because the firewall prevents
decryption when it resets the SSL/TLS connection, ending the handshake.
You can view details of the blocked sessions in the URL Filtering
logs.
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.