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 handshake inspection.
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.