Network Security
Decryption Basics
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
Decryption Basics
Overview of decryption, how it works on Palo Alto Networks appliances, the benefits,
and how to configure SSL or SSH decryption.
Where Can I Use This? | What Do I Need? |
---|---|
|
No requirements.
|
The Transport Layer Security (TLS) protocol, which evolved from the Secure
Sockets Layer (SSL), and the Secure Shell (SSH) protocol secure
communication between two entities, such as a web server and a client. While SSL/TLS
typically secures web-based communications, SSH typically secures remote access to
servers and devices. These protocols use public and private key cryptography to
establish secure connections. They encrypt data in a way that renders it meaningless to
any entity lacking the certificate and keys required to establish trust and decode the
data. However, the privacy and integrity that encryption provides can be exploited. For
example, suppose an attacker installs malware on an HTTPS website, and employees visit
the site and unknowingly download malware. The malware can use the infected employee
endpoint to move laterally through the network and compromise other systems. Thus,
traffic should not be trusted automatically.
Decryption is the process of converting encrypted data into its original format, so that
it's readable. This process allows for inspection and visibility into SSL/TLS and SSH
traffic. You can decrypt both outbound and inbound traffic. SSL Forward Proxy inspects
traffic exiting your internal network to the internet. SSL Inbound
Inspection inspects traffic entering internal network servers. SSH Proxy inspects and controls
traffic in SSH tunnels. Consider that you can’t block traffic that you don't
inspect.
SSH Proxy isn’t supported by Strata Cloud Manager.
Decrypt SSL and SSH traffic to:
- Prevent malicious, encrypted traffic from entering your network.
- Prevent sensitive information from exiting your network.
- Ensure the appropriate applications are running on a secure network.
- Identify noncompliance with legal, corporate, and other policies.
SSL decryption uses keys and certificates to establish a
Next-Generation Firewall (NGFW) as a trusted third party between a client and a server.
The NGFW decrypts SSL/TLS traffic to plaintext for inspection. Then, the
NGFW re-encrypts the traffic before forwarding it to its destination,
ensuring the privacy and security of the data. SSL decryption works with Advanced Threat Prevention, Advanced URL Filtering, and other services that require
packet inspection. Without SSL decryption, you couldn't create exceptions to URL categories for
websites encrypted with HTTPS. It also provides additional use cases for these services.
For example, you can selectively decrypt traffic based on URL categories and apply
threat prevention controls.
SSH decryption does not require certificates. With SSH decryption enabled, an NGFW decrypts and blocks or restricts SSH traffic according to your
decryption policy rules and profiles. It specifically tackles SSH tunneling. The NGFW also re-encrypts the SSH traffic as it exits. You can use Decryption Port Mirroring to forward decrypted traffic to a third-party solution
for additional analysis and archiving. All mirrored traffic, including sensitive
information, is forwarded in cleartext.
Be aware of local laws and regulations about what traffic you can mirror and where
and how you can store the traffic. The use of SSL traffic is regulated in some
countries and jurisdictions.
Palo Alto Networks decryption is policy-based. NGFWs handle encrypted
traffic according to a decryption policy. A decryption policy consists
of one or more decryption policy rules, which specify the traffic targeted for
decrypted, the type of decryption performed, and how certain traffic is handled.
Configure and associate a decryption profile with a decryption policy rule
to define the protocol versions and cipher suites supported by the client (in the case
of SSL decryption) or to configure certificate verification and other checks. For
example, you can create a no-decryption policy rule and profile to bypass decryption of
financial or healthcare data.
Decrypting all traffic indiscriminately can be resource-intensive. When planning for and implementing decryption, balance the need for thorough
inspection with considerations of performance, compliance, security, and resource
management. For example, if performance and sizing are major considerations, you might
prioritize the decryption of traffic to high- or medium-risk URL categories, traffic destined for critical
servers, or business-critical traffic. Some traffic can't be decrypted for technical,
legal, or other reasons. Understand the traffic you can and can’t decrypt when
developing a decryption strategy. Use the Decryption Best Practices Checklist to plan,
implement, and maintain your decryption deployment.
Decryption Support
- NGFWs support Perfect Forward Secrecy (PFS). The Diffie-Hellman (DHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange algorithms are enabled in decryption profiles by default.
- You can store and generate keys using an hardware security module (HSM) integrated with a NGFW or Panorama. HSMs provide enhanced security for the private keys used in SSL Forward Proxy and SSL Inbound Inspection decryption.
- SSL Forward Proxy and SSL Inbound Inspection support SSL session resumption because the NGFW functions as a proxy in both modes.
- High availability (HA) isn’t supported for decrypted sessions. After a failover, a NGFW doesn't support HA sync for decrypted SSL sessions. NGFWs also don’t resume decrypted SSL Forward Proxy, SSL Inbound Inspection, or SSH Proxy sessions. The NGFW decrypts new sessions that start after the failover based on your decryption policy.