Skip to content

TLS Inspection traps — vendor-by-vendor enforcement matrix

Read in your language: English · Português · Español

Scope status (post-Scope-Freeze 2026-05-10) — See ARCHITECTURE.md for the canonical 37 MÓDULOs + 7 Test Kinds + DOM/CPOS/PIE-PA safety architecture. ADRs 0014, 0019-0025 cover post-Freeze additions.

TL;DR

Several NGFW vendors expose two distinct modes for what they loosely call "SSL Inspection" or "TLS Inspection". One inspects only the handshake (cheap, fast, useless for payload threats); the other performs full MITM + DPI on the decrypted payload (the only mode worth measuring).

Some vendors publish performance numbers from the lightweight mode without disclosing the distinction. Numbers measured in the lightweight mode are typically 5-10× higher than real TLS Inspection + DPI numbers — and a customer comparing across vendors gets a misleading apples-to-oranges picture.

This document is the enforcement reference for the per-vendor apply scripts (scripts/ip-apply-<vendor>.sh) and for the operator who wants to know what to look for when validating a setup. The canonical methodology lives in ADR 0010 amendment 2 (rule G3: TLS Inspection without DPI is not a valid test mode).

The trap matrix

Every vendor in the DUT catalog packages the lightweight vs full mode under different names. The apply scripts MUST select the full mode when the active Inspection Profile is non-minimal, and MUST fail loud if asked to configure the lightweight mode.

Vendor Lightweight mode (FORBIDDEN by G3) Full DPI mode (REQUIRED by G3) What G3 looks for in device readback
Fortinet FortiGate "Certificate Inspection" "Deep Inspection" ssl-ssh-profile policy with inspect-all enable and at least one of https-policy, ftps-policy, imaps-policy set to deep-inspection
Cisco FTD (FMC / FDM / SCC) TLS Server Identity Discovery only "Decrypt - Resign" action with attached AVC + IPS + Malware + URL policies SSL Policy on the Access Control Policy with at least one rule of action Decrypt - Resign, AND the rule's matched Access Control rule has Intrusion + File + URL policies attached
Palo Alto PAN-OS "Decrypt - No Profile" / "Mirror" only "Decrypt" action with a Decryption Profile attached + Security Policy with Vulnerability + Anti-Spyware + URL Filtering + WildFire profiles Decryption Policy rule with action decrypt, attached Decryption Profile must have block-unsupported-version, block-unknown-cert; matching Security Policy must have a Security Profile Group
Check Point Quantum / Force HTTPS Categorization only Inbound + Outbound HTTPS Inspection + Threat Prevention layer (IPS / Anti-Bot / Anti-Virus / Threat Emulation) HTTPS Inspection layer enabled (not just Categorize HTTPS sites); Threat Prevention profile attached to the matching Access Rule
HPE Juniper SRX "Application-First" without SSL Forward Proxy SSL Forward Proxy + IDP + URL Filter + Sky ATP / Juniper ATP services ssl proxy profile configured; security policy attaches the proxy profile + IDP policy + AppFW + URL filtering
Sophos XGS Web Protection without SSL/TLS Inspection rules SSL/TLS Inspection rules with action Decrypt and inspect + linked IPS / AV / Application Control rules At least one SSL/TLS Inspection rule with action Decrypt and inspect; matching firewall rule references Web Protection + IPS + AV + Application Control
Forcepoint NGFW TLS Application Identification only TLS Inspection rule + Deep Inspection profile + Anti-Malware scan + URL Filtering TLS Inspection rule with Decrypt action; inline Inspection policy with Deep Inspection enabled, Anti-Malware policy attached
WatchGuard Firebox HTTPS Content Inspection only HTTPS DPI with full proxy + IPS + Application Control + Gateway AV + APT Blocker HTTPS proxy with Content Inspection enabled and Inspect SNI not the only action; downstream proxy actions reference IPS, AppControl, GAV, APT Blocker
Huawei NGFW TLS visibility (no decryption) SSL/TLS Decryption Policy + IPS profile + AV profile + URL filtering profile tls-decryption-policy rule with action decrypt; security policy attached to the inspected zone references IPS / AV / URL profiles

How the bench enforces this at run time

Three layers of defense, each independent:

Layer 1 — ip-apply-<vendor>.sh refuses to configure the lightweight mode

Every per-vendor apply script (PR-B onward) implements an explicit guard:

# Pseudocode common to every vendor adapter
if [[ "$INSPECTION_PROFILE" != "minimal" ]] && \
   [[ "$DETECTED_MODE" == "lightweight" ]]; then
  fail "G3 violation: profile '$INSPECTION_PROFILE' requires full TLS Inspection + DPI; \
        device is in '$VENDOR_LIGHTWEIGHT_MODE_NAME' mode. \
        See docs/TLS_INSPECTION_TRAPS.md."
fi

The vendor-specific lightweight mode name (Certificate Inspection, Decrypt - No Profile, HTTPS Categorization, etc.) comes from the trap matrix above.

Layer 2 — ip-verify-<vendor>.sh reads back the running policy state

After apply succeeds, the verify script polls the device's management API to confirm:

  • The TLS / SSL profile attached to the active rule has the decrypt action set (not categorize / identify / mirror).
  • The matching firewall rule has the security profile group / threat prevention layer / IDP policy / DPI engine attached.
  • The "what's looked for" column of the trap matrix above describes exactly what each verifier checks per vendor.

If the readback shows lightweight mode, verify fails the run before agents even launch.

Layer 3 — Annex K of the report attests the inspection mode

The Test Run Report's Annex K (Inspection Profile Attestation, shipped in PR-D of v4.5) prints the device-side mode read back at both apply time and verify time. If they ever differ, or if either shows lightweight mode under a non-minimal profile, the report cover marks the run INVALID with a red flag, and the comparison charts in the body refuse to plot the run alongside other runs.

This is the single most important defensibility mechanism in the project — it prevents a customer from accidentally (or maliciously) publishing a number that looks comparable to other vendors but is actually a lightweight-mode measurement.

What makes the trap so effective in the wild

Three reasons customers fall into it without noticing:

  1. The dashboard shows a green check mark. Vendor management UIs typically display "TLS Inspection: Enabled" the moment the lightweight mode is on — there is no separate UI cue for "mode is actually inspecting only the handshake".

  2. Throughput is gloriously high. Customers measure post-deployment throughput, see numbers matching the datasheet, and conclude the NGFW is performing as advertised. The actual security posture is nowhere near what the dashboard claims.

  3. The vendor's own marketing is ambiguous. Datasheet performance tables sometimes specify "TLS 1.2 with AES256-SHA, RSA 2048B keys" without disclosing whether the payload is decrypted. Read carefully — if there is no mention of "Application Visibility and Control" or "IPS" or "Threat Detection" in the same row as the TLS throughput number, suspect the lightweight mode.

Operator quick-check before every test run

When manually validating a setup (preflight will do this automatically when the per-vendor scripts ship):

  1. Open the vendor's management UI for the active TLS / SSL inspection policy.
  2. Find the policy / rule that's processing test traffic (cross-reference with the destination subnet of your test plan's persona pool).
  3. Confirm the action is NOT in the "FORBIDDEN" column of the trap matrix above.
  4. Confirm the rule has the security profile group / IPS policy / DPI engine attached.
  5. If the management UI is ambiguous (some vendors are), use the vendor's CLI / API to read the policy verbatim and grep for the keywords in the "What G3 looks for" column.

If any of these is in doubt, the test result is not comparable to any other vendor — re-run after the misconfig is fixed.

References

  • ADR 0010 amendment 2 — methodology + the G3 + G4 rule definitions
  • DUT Catalog — every model carries capabilities.tls_decryption_hw_accel: true|false indicating whether the chassis can sustain DPI mode at line rate
  • RFC 9411 — Benchmarking Methodology for Network Security Device Performance (March 2023) — §6 enumerates the same dial set this document maps onto, vendor-agnostic
  • NetSecOPEN test methodology documents — uniformly use "TLS Inspection" terminology and require DPI mode as part of the certified-test profile