7.2 HTTPS Content Inspection & TLS Decryption

7.2 HTTPS Content Inspection & TLS Decryption

Quick Answer: Modern web traffic is overwhelmingly encrypted using TLS 1.2 and TLS 1.3, creating a critical security blind spot where malware, phishing URLs, and data exfiltration remain hidden from standard firewall filters. WatchGuard's HTTPS Content Inspection (Deep Packet Inspection / DPI) solves this by acting as a trusted man-in-the-middle: the Firebox terminates the client TLS handshake, generates an on-the-fly certificate re-signed by its Proxy Authority CA, and establishes an independent TLS session with the external server. Inside the Firebox memory buffer, decrypted plaintext is scanned by Gateway AntiVirus, IntelligentAV, APT Blocker, IPS, and WebBlocker before being re-encrypted. To avoid browser security warnings, administrators must distribute the Proxy Authority CA certificate to all client endpoints via Active Directory Group Policy (GPO) or import an Enterprise Subordinate CA signed by their internal PKI.

---

The Encrypted Traffic Blind Spot

Historically, the vast majority of web traffic traversed the Internet in cleartext HTTP over TCP port 80. Firewalls easily inspected URLs, read headers, and scanned transferred files for viruses. However, the widespread adoption of Transport Layer Security (TLS 1.2 and TLS 1.3) has transformed enterprise networking: today, more than 90% of all outbound web connections utilize HTTPS across TCP port 443.

While TLS provides essential privacy and cryptographic integrity between web servers and clients, it simultaneously creates a severe security blind spot for enterprise defenders:

• Opaque Payloads: When traffic is encrypted, a standard firewall packet filter or uninspected proxy sees only a stream of pseudorandom cipher bytes. It cannot determine whether an outbound session contains an employee accessing a corporate portal or an infected host downloading a polymorphic ransomware binary.
• Invisible Full URLs: TLS encryption encapsulates the HTTP request line. While the destination server's domain name can often be discerned from the Server Name Indication (SNI) header during the initial handshake, the specific URL path (e.g., /malware/dropper.exe), query strings, and form parameters are completely invisible.
• Subscription Engine Blindness: Security subscription services—including Gateway AntiVirus (GAV), IntelligentAV, Intrusion Prevention Service (IPS), and APT Blocker—rely on string matching, heuristic evaluation, and binary decompression. If an HTTPS session is not decrypted, these engines cannot inspect the payload, rendering perimeter defenses largely ineffective against web-delivered threats.

+---------------------------------------------------------------------------------------------------+
|                         THE ENCRYPTED TRAFFIC BLIND SPOT (PORT 443)                               |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  WITHOUT HTTPS CONTENT INSPECTION:                                                                |
|  [Client] ======= Encrypted TLS Session (Port 443) =======> [Firebox] =======> [External Server]  |
|                                                                 |                                 |
|  • Firewall sees: Source IP, Dest IP, Port 443, SNI Domain      |                                 |
|  • Firewall CANNOT see: Full URL Path, Payloads, Files, Headers |                                 |
|  • Security Subscriptions (GAV, IPS, APT Blocker): BLIND        x (Payload passed uninspected)    |
|                                                                                                   |
|  WITH HTTPS CONTENT INSPECTION (DEEP PACKET INSPECTION):                                          |
|  [Client] <== TLS Session 1 ==> [Firebox Proxy] <============= TLS Session 2 ===========> [Server]|
|                                        |                                                          |
|                                 Plaintext Buffer                                                  |
|                                        |                                                          |
|                         +--------------+--------------+                                           |
|                         | FULL SUBSCRIPTION INSPECTION|                                           |
|                         | • Gateway AntiVirus (GAV)   |                                           |
|                         | • APT Blocker (Sandbox)     |                                           |
|                         | • IPS Exploit Signatures    |                                           |
|                         | • WebBlocker Full URL Paths |                                           |
|                         | • IntelligentAV (PE binaries)|                                          |
|                         +-----------------------------+                                           |
+---------------------------------------------------------------------------------------------------+

---

Deep Packet Inspection (DPI) Mechanics

To inspect encrypted web traffic, the Firebox must act as an inline, trusted man-in-the-middle (MITM). In Fireware OS, this capability is implemented within the HTTPS-proxy policy and is designated as Content Inspection.

Step-by-Step Cryptographic Workflow of HTTPS Inspection

When an internal client initiates an HTTPS connection to an external secure web server (e.g., https://www.example.com), Fireware executes a sophisticated multi-stage cryptographic and inspection sequence:

1. Client TLS Handshake Interception: The client initiates a TLS handshake by sending a ClientHello message targeting TCP port 443. The Firebox intercepts this packet and halts the direct connection to the external server.
2. Upstream Server Handshake & Certificate Validation: The Firebox initiates an independent TLS handshake with the destination external server (www.example.com). The server returns its public SSL/TLS certificate. The Firebox rigorously validates the server's certificate:
   • It checks that the certificate has not expired and is currently valid.
   • It verifies that the certificate was issued by a trusted public Certification Authority (CA) found in the Firebox's local root CA store.
   • It checks certificate revocation status via Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP).
   • It verifies that the Common Name (CN) or Subject Alternative Name (SAN) matches the requested domain.
3. Dynamic Certificate Generation (Re-Signing): If the external server's certificate is valid, the Firebox dynamically generates a new, synthetic X.509 certificate on the fly. This synthetic certificate duplicates the Subject, Common Name, and SAN fields of the original web server certificate, but it is signed by the Firebox's own internal Proxy Authority CA private key.
4. Client Handshake Completion (Connection 1): The Firebox transmits this synthetic re-signed certificate to the internal client. The client validates the certificate against its local operating system trust store. Because the client trusts the Firebox Proxy Authority CA, the handshake succeeds without error. Symmetric encryption keys are negotiated between the client and the Firebox.
5. Server Handshake Completion (Connection 2): Simultaneously, the Firebox completes the independent TLS handshake with the external server, negotiating a completely separate set of symmetric encryption keys.
6. Decryption and Plaintext Inspection Bridge: When the client sends an encrypted HTTP request (e.g., GET /downloads/software.exe), the Firebox decrypts the ciphertext into cleartext using the Session 1 key. The cleartext data is placed in a secure kernel memory buffer. At this stage, the Firebox passes the decrypted stream to an internal HTTP-Client proxy action.
7. Security Subscription Scanning:
   • WebBlocker inspects the full URL path and query arguments.
   • Gateway AntiVirus reconstructs downloaded files and scans byte patterns.
   • APT Blocker extracts suspicious executables or documents and sends cryptographic hashes (or full files) to the cloud sandbox.
   • Intrusion Prevention Service (IPS) checks for buffer overflows and exploit signatures.
   • IntelligentAV evaluates Windows Portable Executable binaries with its machine-learning model.
8. Re-Encryption and Transmission: If all security subscriptions declare the traffic clean, the Firebox takes the cleartext data, encrypts it using the Session 2 key negotiated with the external server, and transmits it across the WAN.

---

Firebox Certificate Authority (CA) Architecture

The entire cryptographic validity of HTTPS Content Inspection depends on the Proxy Authority Certification Authority (CA) certificate. If client endpoints do not trust the CA that signs the Firebox's synthetic certificates, every HTTPS website visited by users will trigger severe browser security warnings.

+---------------------------------------------------------------------------------------------------+
|                         FIREBOX CERTIFICATE AUTHORITY (CA) HIERARCHY                              |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  OPTION A: DEFAULT SELF-SIGNED CA                   OPTION B: ENTERPRISE SUBORDINATE CA           |
|                                                                                                   |
|  [Firebox Self-Signed Root CA]                      [Active Directory Enterprise Root CA]         |
|  • Generated locally during setup                   • Pre-trusted by all domain computers         |
|  • Private key stored on Firebox                    • Root of enterprise PKI hierarchy            |
|         |                                                           |                             |
|         | (Must export .cer & deploy                                | Issues Subordinate CA cert  |
|         |  to every endpoint via GPO)                               v                             |
|         v                                           [Firebox Proxy Authority (Intermediate CA)]   |
|  [Client Trusted Root Store]                        • CSR signed by Enterprise Root CA            |
|  • Manual or GPO trust required                     • Automatically trusted by all domain PCs!    |
+---------------------------------------------------------------------------------------------------+

Default Firebox Proxy Authority CA

When a Firebox is initialized, Fireware automatically creates a self-signed root certificate named the Proxy Authority certificate:

• Cryptographic Characteristics: Generated with a 2048-bit RSA key and a validity period of several years. Both the public certificate and the private signing key reside in the Firebox's secure flash storage.
• The Trust Problem: Because this default CA was generated by the local appliance, no external operating system, browser, or mobile device recognizes or trusts it out of the box. If an administrator enables HTTPS Content Inspection without deploying this certificate, every user attempting to access an HTTPS website receives an error such as NET::ERR_CERT_AUTHORITY_INVALID (in Google Chrome/Edge) or SEC_ERROR_UNKNOWN_ISSUER (in Mozilla Firefox).
• Deployment Requirement: Administrators must manually export the public certificate from the Firebox and distribute it to all client devices.

Third-Party Enterprise Subordinate CA (Best Practice)

In enterprise environments with an established internal Public Key Infrastructure (PKI)—such as Microsoft Active Directory Certificate Services (AD CS)—the recommended architectural best practice is to configure the Firebox as a Subordinate (Intermediate) CA:

1. The administrator generates a Certificate Signing Request (CSR) on the Firebox specifying the Proxy Authority role.
2. The CSR is submitted to the corporate Enterprise Root CA, which issues a Subordinate CA certificate with the Certificate Signing key usage attribute enabled.
3. The administrator imports the signed Subordinate CA certificate and private key onto the Firebox.
4. The Critical Advantage: Because all corporate domain computers already possess and trust the Enterprise Root CA certificate through normal Active Directory domain enrollment, they automatically trust any intermediate certificate issued by that root. The administrator does not need to deploy a new root certificate to thousands of workstations, drastically streamlining deployment.

Architectural Comparison: Default CA vs. Enterprise Subordinate CA

---

Exporting and Deploying Certificates via Active Directory GPO

For organizations utilizing the default Firebox Proxy Authority CA, the administrator must export the public certificate from the appliance and deploy it to all network endpoints via Active Directory Group Policy.

+---------------------------------------------------------------------------------------------------+
|                         CERTIFICATE EXPORT AND GPO DISTRIBUTION WORKFLOW                          |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  STEP 1: FIREBOX EXPORT                                                                           |
|  Fireware Web UI: System > Certificates  OR  Policy Manager: Setup > Certificates                 |
|  • Select: 'Proxy Authority' Certificate                                                          |
|  • Click: Export                                                                                  |
|  • Format: Base-64 Encoded X.509 (.cer)                                                           |
|  • CRITICAL: Only the PUBLIC certificate is exported; private key never leaves the Firebox!       |
|                                                                                                   |
|           |                                                                                       |
|           v                                                                                       |
|                                                                                                   |
|  STEP 2: ACTIVE DIRECTORY GPO CONFIGURATION                                                       |
|  Open Group Policy Management Console (gpmc.msc) on Domain Controller                             |
|  • Create GPO: 'Firebox-Proxy-CA-Deployment' linked to Domain Root or Workstations OU             |
|  • Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings          |
|                 > Public Key Policies > Trusted Root Certification Authorities                    |
|  • Right-click > Import > Select exported Firebox Proxy Authority .cer file                       |
|                                                                                                   |
|           |                                                                                       |
|           v                                                                                       |
|                                                                                                   |
|  STEP 3: CLIENT ENDPOINT PROPAGATION                                                              |
|  • Workstations receive GPO during background refresh or via 'gpupdate /force'                    |
|  • Certificate installs into Windows Local Machine Root Certificate Store (certlm.msc)           |
|  • Chrome, Edge, and modern Firefox trust re-signed HTTPS connections without warning prompts     |
+---------------------------------------------------------------------------------------------------+

Step-by-Step Certificate Export Procedure

1. Log in to the Fireware Web UI and navigate to System > Certificates, or open Policy Manager and select Setup > Certificates.
2. In the certificate list, locate the certificate with the purpose labeled Proxy Authority.
3. Click Export.
4. Select the format: Base-64 encoded X.509 (.cer or .pem).
5. Save the file to a secure management workstation. Note that this exported file contains only the public key and identity attributes of the CA. The private key used for cryptographic signing remains securely sealed within the Fireware cryptographic key store and cannot be extracted via this process.

Step-by-Step Active Directory GPO Deployment Procedure

1. On a Windows Server Domain Controller or administrative workstation equipped with RSAT, open the Group Policy Management Console (gpmc.msc).
2. Create a new Group Policy Object (e.g., Deploy_WatchGuard_Proxy_Authority_CA) and link it to the appropriate Organizational Unit (OU) containing all target computer accounts.
3. Right-click the GPO and select Edit to open the Group Policy Management Editor.
4. Navigate to the following path: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
5. Right-click Trusted Root Certification Authorities and select Import.
6. In the Certificate Import Wizard, browse to and select the exported .cer file.
7. Complete the wizard, ensuring the certificate is placed explicitly into the Trusted Root Certification Authorities store.

Client Verification and Operating System Nuances

• Windows Domain Endpoints: When client workstations process the GPO (which occurs automatically at computer startup and every 90 minutes in the background, or instantly by running gpupdate /force in an elevated command prompt), the certificate is injected into the Local Machine certificate store (certlm.msc).
• Browser Integration: Google Chrome, Microsoft Edge, and modern versions of Mozilla Firefox (which default to querying the Windows Certificate Store via security.enterprise_roots.enabled = true) will immediately recognize and validate re-signed certificates. Users can browse inspected HTTPS sites without seeing security prompts.
• macOS and Linux Endpoints: Non-Windows devices must have the certificate installed via Mobile Device Management (MDM) platforms (such as Jamf or Microsoft Intune) into the macOS System Keychain (configured for Always Trust), or placed into /etc/ssl/certs/ or /usr/local/share/ca-certificates/ followed by running update-ca-certificates on Linux.