Network Security
TLS 1.3 Decryption
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
TLS 1.3 Decryption
Decrypt TLSv1.3 traffic to protect against threats in encrypted traffic while
benefiting from TLSv1.3 application security and performance improvements.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
No requirements.
|
TLSv1.3 is the latest version of the TLS protocol, improving application security and
performance. Next-Generation Firewalls (NGFW and Prisma Access
support TLSv1.3 for SSL Forward Proxy and SSL Inbound Inspection decryption,
decrypted Network Packet Broker traffic, and Decryption Port Mirroring. This support enables you to decrypt, gain full
visibility into, and prevent known and unknown threats in TLSv1.3 traffic.
To support TLSv1.3 decryption, apply a decryption profile with TLSv1.3 configured as the
minimum or maximum protocol version to existing and new decryption policy rules. You can
edit existing decryption profiles to support TLSv1.3. If you don’t enable TLSv1.3,
PAN-OS defaults to TLSv1.2 as the maximum protocol version. If a website or application
doesn't support TLSv1.3, the Next-Generation Firewall (NGFW) automatically selects a TLS
protocol version that the server supports.
To establish a TLSv1.3 connection, both client and server must support negotiation with
TLSv1.3 ciphers. The following decryption algorithms are supported for TLSv1.3
connections:
- TLS13-AES-128-GCM-SHA256
- TLS13-AES-256-GCM-SHA384
- TLS13-CHACHA20-POLY1305-SHA256
If the Max Version a decryption profile supports is
Max, then the profile supports TLSv1.3 and automatically uses
TLSv1.3 with sites supporting this protocol. The Max option
ensures that the traffic that the profile controls uses the strongest available protocol
version. It also future-proofs the decryption profile as it provides automatic support
for new TLS versions as they are released.
You can configure TLSv1.3 as the
Max Version instead of Max. However,
when the next TLS version releases, you'll need to update the decryption
profile.
Min Version specifies the weakest version of the protocol that the
traffic can use. Setting the minimum protocol version to TLSv1.3
achieves the tightest security because it requires traffic to use TLSv1.3 or greater
protocol versions. This blocks weaker protocols and makes weaker key exchange,
encryption, and authentication algorithms unavailable. Further, TLSv1.3 requires the use
of Perfect Forward Secrecy (PFS). Apply a profile
that sets TLSv1.3 as the minimum version only to application traffic that only supports
TLSv1.3.If
As not all applications support TLSv1.3, follow decryption best practices and set the
Min Version of the TLS protocol to
TLSv1.2 and the Max Version to
Max. If access to websites or applications with weaker TLS
protocols is a business requirement, create separate decryption profiles with a
Min Version that allows the weaker protocol and attach it to
a decryption policy rule that specifies the traffic you need to allow with the weaker
TLS protocol.
For decryption policy rules that support mobile applications, many of which use pinned
certificates, set the Max Version to
TLSv1.2. TLSv1.3 encrypts certificate information that was
not encrypted in previous TLS versions, preventing NGFWs from
automatically adding decryption exclusions based on certificate information. As a
result, if you enable TLSv1.3, the NGFW may drop some mobile application
traffic. To mitigate potential issues, create a No Decryption policy rule for this
traffic. If you know the specific mobile applications required for business, consider
creating a separate decryption policy rule and decryption profile for those
applications. This approach allows you to enable TLSv1.3 for all other traffic.
Avoid attaching No-decryption profiles to decryption policy rules that exclusively
handle TLSv1.3 traffic. TLSv1.3 encrypts certificate information, so the NGFW doesn't have visibility into this information and therefore
can’t block sessions with expired certificates or untrusted issuers, making the
profile ineffective. (The NGFW can perform certificate checks with
TLSv1.2 and earlier protocols because those protocols don’t encrypt certificate
information. You should apply No Decryption profiles to decryption policy rules
handling TLSv1.2 and earlier traffic.) However, you can log undecrypted traffic of
all types by selecting the options to log successful and unsuccessful TLS handshakes
in decryption policy rules. Unsuccessful TLS handshakes are logged by default.
If you allow unsupported modes in the SSL Protocol Settings of a decryption profile, the NGFW and
Prisma Access automatically adds this traffic to its Local SSL Decryption Exclusion Cache.The NGFW and Prisma Access still decrypts and
inspects traffic that is downgraded from TLSv1.3 to TLSv1.2. The
Reason shown in the cache for the added servers is
TLS13_UNSUPPORTED.
If you downgrade from PAN-OS 11.1 to a previous version, any decryption profile that
specifies TLSv1.3 as the Min Version or the Max
Version changes to the highest supported version. For example,
downgrading from PAN-OS 11.1 to PAN-OS 9.1 replaces TLSv1.3 with TLSv1.2. If a Panorama
device on PAN-OS 11.1 pushes the configuration to devices that run older versions of
PAN-OS, any decryption profile that specifies TLSv1.3 as the Min
Version or the Max Version also changes to the
highest supported version.