Valid Parameters for SSL Decryption Policies
Scenario Question Recap:
When configuring SSL Decryption, what are three valid parameters (match criteria) that can be used in an SSL Decryption policy rule?
SSL Decryption policies on Palo Alto Networks firewalls control which encrypted traffic (SSL/TLS) should be intercepted and decrypted for further inspection (like App-ID and Threat Prevention). Similar to Security Policies, these rules use specific parameters to match traffic.
Valid SSL Decryption Policy Match Criteria
According to Palo Alto Networks documentation, the following are primary parameters you can use to define the match criteria for an SSL Decryption rule:
-
Source Zones and Destination Zones:
Define the flow direction (e.g., from trust zone to untrust zone).
-
Source IP Addresses and Destination IP Addresses:
Specify individual IPs, subnets, or Address Objects/Groups.
-
Source Users:
Target specific users or user groups learned via User-ID (LDAP, Agent, GlobalProtect, etc.).
-
URL Categories:
Match based on predefined or custom URL categories (requires PAN-DB or BrightCloud license). Commonly used to decrypt risky categories or exclude sensitive ones (like financial or health).
-
Services:
Match based on the destination port or predefined Service Objects (e.g.,
service-https
,
service-ssl
, or custom services).
Using these criteria allows administrators to precisely target which traffic flows should undergo decryption.
📘 Explanation of Correct Options from Scenario
-
Source Users:
Allows targeting specific users or Active Directory/LDAP groups for decryption, often used during phased rollouts or for specific compliance requirements.
-
URL Categories:
Enables selective decryption based on the website's category. A common practice is to decrypt categories known to host malware or phishing sites, while potentially excluding categories like Financial Services or Health and Medicine for privacy reasons.
-
Source and Destination IP Addresses:
Fundamental criteria for defining traffic flows, allowing decryption policies to target specific internal networks communicating with external resources, or specific servers requiring inbound inspection.
Why Other Options Are Incorrect Match Criteria
1. GlobalProtect HIP (Host Information Profile)
-
❌ HIP Profiles assess the security posture of connecting endpoints (e.g., OS patch level, AV status). While HIP data can be used as match criteria in
Security Policies
and
GlobalProtect Gateway
configurations (to allow/deny access or apply QoS), it is **not** a valid match criterion directly within an **SSL Decryption policy rule**.
3. App-ID (Application Identification)
-
❌ This is a critical point: SSL Decryption must happen **before** the firewall can identify the specific application (App-ID) running inside the encrypted tunnel. Therefore, you cannot use App-ID as a match criterion in the SSL Decryption policy itself, because the application is unknown until *after* decryption occurs. Decryption policies operate primarily on Layer 3/Layer 4 information (IPs, ports, users) and Layer 7 information available *before* decryption (like URL category from SNI/certificate).
(Placeholder: Insert Mermaid diagram image here if available)
✅ Summary: SSL Decryption policies primarily use Zone, IP Address, User, URL Category, and Service/Port information as match criteria. App-ID and HIP profiles are used in other policy types, not directly for matching traffic *to be decrypted*.