Preparing for Decryption Deployment

Introduction: Why Plan?

Successfully deploying SSL/TLS or SSH decryption involves more than just configuring firewall policies. Careful planning is essential to ensure the deployment meets security goals without disrupting users or violating regulations. Key preparation steps involve stakeholder alignment, developing a clear strategy, managing certificates (PKI), correctly sizing hardware, and executing a phased rollout.

Goal: Decrypt as much traffic as feasible to maximize visibility and threat prevention, while respecting technical limitations, performance constraints, and policy/legal requirements.

Phase 1: Strategy Development with Stakeholders

Effective decryption requires buy-in and input from various departments:

• Legal/Compliance: Understand regulations (e.g., GDPR, HIPAA) regarding privacy and data handling for different traffic types (financial, health). Obtain necessary approvals.
• HR: Update computer usage policies to inform users about traffic inspection. Define handling for sensitive employee data.
• Finance/Executives: Define policies for sensitive financial data and potentially different decryption rules for executive traffic.
• IT/Support: Prepare support teams for potential user issues during rollout and establish troubleshooting procedures.
• Security Team: Define risk tolerance, prioritize assets and traffic types, and align decryption goals with the overall security posture.

Key Strategic Decisions:

1. Define Scope & Priorities:
   • Identify critical internal servers needing protection (Inbound Inspection candidates).
   • Categorize outbound traffic by risk (e.g., High-Risk URL categories, unclassified sites) and business need.
   • Prioritize decryption for the highest risk traffic first, especially if firewall resources are constrained. Ask: "What's the impact if this encrypted traffic contains malware?"
2. Identify Technical Exclusions:
   • Proactively test or research applications/sites known to use certificate pinning or require mutual authentication, which inherently break Forward Proxy decryption.
   • Identify destinations using unsupported ciphers or protocols that cannot be decrypted.
   • For business-critical sites that break decryption technically, add them to the global SSL Decryption Exclusion List (Device > Setup > Session > Decryption Settings). This list is *only* for technical exclusions.
3. Identify Policy-Based Exclusions:
   • Determine traffic categories that should *not* be decrypted due to privacy, legal, or policy reasons (e.g., Financial Services, Health and Medicine).
   • Create specific Decryption Policy rules with a "No Decrypt" action for these categories.
   • Attach a "No Decryption" Decryption Profile to these rules to perform basic certificate validation (block expired/untrusted CAs) for TLS 1.2 and earlier traffic, adding a layer of security even without full decryption.
4. Handle Guest & BYOD Traffic:
   • **Best:** Isolate these networks. If no corporate access is needed, direct them straight to the internet without decryption.
   • **If corporate access needed:** Decrypt their traffic. This requires a method (e.g., Captive Portal, instructions) for users to trust the firewall's Forward Trust CA. Update usage policies accordingly. Apply strict Security Policies.
   • **If decryption legally prohibited:** Isolate the network segment, apply strict Security Policies (App-ID, URL Filtering, Threat Prevention), and use a "No Decrypt" policy rule with a profile to block connections with invalid certificates (for TLS 1.2-).
5. Define Logging Strategy: Determine which decryption events (successes, failures, exclusions) to log and forward, considering storage capacity and compliance requirements. Securely store forwarded logs.

Decryption Decision Flow

graph TD
    A[Traffic Matches Security Policy 'Allow'] --> B{Decryption Policy Match?};
    B -- Yes --> C{Action: Decrypt?};
    B -- No --> Z[Allow Undecrypted];
    C -- Yes --> D[Technically Possible? No Pinning mTLS Unsupported Cipher...];
    C -- No --> E[Action: No Decrypt];
    D -- Yes --> F[Decrypt Traffic];
    D -- No --> G{Check Global Exclusion List};
    G -- Yes --> Z;
    G -- No --> H[Block/Drop Session];
    E -- Apply Checks --> I{Certificate Valid? If Profiled};
    I -- Yes --> Z;
    I -- No --> H;
    F --> J[Inspect Cleartext App-ID Threat URL...] --> K[Re-encrypt & Forward];

    style Z fill:#dff0d8,stroke:#3c763d,stroke-width:2px;
    style H fill:#f2dede,stroke:#a94442,stroke-width:2px;

        

Phase 2: Public Key Infrastructure (PKI) Planning

SSL Forward Proxy requires the firewall to dynamically create certificates impersonating the destination server, signed by a CA that internal clients trust. Planning your PKI strategy is critical:

• Option 1 (Best Practice): Enterprise PKI Integration
  • Issue subordinate CA certificates from your existing trusted internal Enterprise Root CA specifically for firewall decryption (one Forward Trust CA, one Forward Untrust CA).
  • **Advantage:** Client devices likely already trust the Enterprise Root CA, simplifying deployment. Management is centralized.
  • **Recommendation:** Generate a *unique subordinate Forward Trust CA* for each firewall (or HA pair) for easier revocation and troubleshooting. A single Forward Untrust CA can be shared across firewalls.
• Option 2: Firewall-Generated Self-Signed CA
  • Generate a self-signed Root CA directly on the firewall.
  • Generate subordinate Forward Trust and Forward Untrust CAs signed by this firewall Root CA.
  • **Requirement:** This firewall-generated Root CA must be distributed and installed as trusted on *all* client devices that will have their traffic decrypted.
  • **Use Case:** Suitable for small environments, labs, or POCs, but less scalable for large enterprises.

Consider using a Hardware Security Module (HSM) for enhanced protection of the private keys associated with your Forward Trust CA(s).

Phase 3: Firewall Sizing for Decryption

Decryption adds computational load to the firewall's dataplane, impacting throughput and session capacity. Accurate sizing is essential to avoid performance degradation.

Factors Affecting Performance:

• Percentage of Traffic Decrypted: Higher percentage = higher load.
• Traffic Volume & Session Rate: More traffic and more new sessions per second increase load.
• TLS Protocol Version: TLS 1.3 handshakes can be faster, but overall decryption impact depends on algorithms.
• Key Exchange Algorithm: PFS algorithms (ECDHE, DHE) are generally more CPU-intensive during session setup than static RSA (used in TLS 1.2).
• Encryption/Authentication Algorithms: Modern algorithms like AES-GCM are efficient, especially with hardware acceleration (common in PA hardware). Older algorithms like 3DES are inefficient.
• Key Sizes: Larger keys provide more security but require more processing power.
• Average Transaction Size: Many small transactions can cause higher session setup overhead relative to data transfer compared to fewer large transactions.
• Firewall Model & Hardware Resources: Newer models have more powerful processors optimized for cryptographic operations.

Sizing Strategy:

• Work with Palo Alto Networks SEs/CEs and use official sizing tools/datasheets.
• Analyze current traffic patterns (total volume, SSL/TLS percentage, average session size).
• Estimate the impact based on the planned decryption scope and profile settings (prioritize decryption of high-risk traffic if resources are limited).
• Plan for future growth in encrypted traffic volume. Gartner has predicted significant increases in encrypted web traffic and malware using encryption.
• Consider the trade-off: using less CPU-intensive algorithms (like RSA for TLS 1.2) for lower-risk traffic can save resources but reduces security compared to using PFS everywhere.

Phase 4: Staged Rollout and User Education

Deploying decryption should be gradual and well-communicated:

1. User Education & Policy Updates: Inform all users (employees, contractors, guests if applicable) about the decryption process, why it's necessary, and how it might affect their browsing (e.g., potential warnings for untrusted sites, blocking of certain sites). Update acceptable use policies.
2. Pilot/POC Phase:
   • Select a small group of early adopters or IT staff for initial testing.
   • Deploy decryption policies for this group, starting with high-risk categories or specific applications.
   • Gather feedback on user experience, website compatibility issues, and performance.
   • Identify sites/apps requiring technical exclusions and add them to the global exclusion list.
   • Refine Decryption Profiles and Policies based on findings.
   • Test support procedures.
3. Phased Production Rollout:
   • Gradually expand decryption to larger user groups or more URL categories/applications.
   • Monitor firewall performance (CPU, memory, session capacity) closely at each stage.
   • Monitor logs (Decryption, Traffic, URL Filtering) for errors or unexpected blocks.
   • Communicate clearly with users during each phase.
   • Adjust policies and exclusions as needed.
4. Ongoing Maintenance: Regularly review decryption logs, exclusion lists, and performance metrics. Update policies and profiles as needed for new applications, threats, or changing requirements.

Consider enabling the "SSL Decryption Opt-Out" feature if required by policy, allowing users encountering issues (or accessing sensitive personal sites) to temporarily bypass decryption after acknowledging a warning.