Skip to content

Trampas de TLS Inspection — matriz de enforcement por fabricante

Lee en tu idioma: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — Ver ARCHITECTURE.md para los 37 MÓDULOs canónicos + 7 Test Kinds + arquitectura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cubren adiciones post-Freeze.

Resumen

Varios fabricantes de NGFW exponen dos modos distintos para lo que llaman genéricamente "SSL Inspection" o "TLS Inspection". Uno inspecciona solo el handshake (barato, rápido, inútil para amenazas en el payload); el otro ejecuta MITM completo + DPI sobre el payload descifrado (el único modo que vale medir).

Algunos fabricantes publican números de performance en el modo liviano sin explicitar la distinción. Los números medidos en modo liviano son típicamente 5-10× mayores que los números reales de TLS Inspection + DPI — y un cliente comparando entre fabricantes recibe una comparación engañosa de manzanas con naranjas.

Este documento es la referencia de enforcement para los scripts apply por fabricante (scripts/ip-apply-<vendor>.sh) y para el operador que necesita saber qué mirar al validar un setup. La metodología canónica está en ADR 0010 amendment 2 (regla G3: TLS Inspection sin DPI no es un modo de prueba válido).

La matriz de trampas

Cada fabricante en el catálogo DUT empaqueta el modo liviano vs completo bajo nombres distintos. Los apply scripts OBLIGATORIAMENTE seleccionan el modo completo cuando el Inspection Profile activo es no-minimal, y OBLIGATORIAMENTE fallan loud si se les pide configurar el modo liviano.

Fabricante Modo liviano (PROHIBIDO por G3) Modo DPI completo (REQUERIDO por G3) Lo que G3 busca en el readback del device
Fortinet FortiGate "Certificate Inspection" "Deep Inspection" Profile ssl-ssh-profile con inspect-all enable y al menos uno de https-policy, ftps-policy, imaps-policy seteado en deep-inspection
Cisco FTD (FMC / FDM / SCC) TLS Server Identity Discovery solamente Acción "Decrypt - Resign" con políticas AVC + IPS + Malware + URL adjuntas SSL Policy en la Access Control Policy con al menos una rule con acción Decrypt - Resign, Y la regla Access Control correspondiente tiene políticas Intrusion + File + URL adjuntas
Palo Alto PAN-OS "Decrypt - No Profile" / "Mirror" solamente Acción "Decrypt" con Decryption Profile adjunto + Security Policy con perfiles Vulnerability + Anti-Spyware + URL Filtering + WildFire Decryption Policy rule con action decrypt, Decryption Profile adjunto debe tener block-unsupported-version, block-unknown-cert; Security Policy correspondiente debe tener un Security Profile Group
Check Point Quantum / Force HTTPS Categorization solamente HTTPS Inspection (Inbound + Outbound) + capa Threat Prevention (IPS / Anti-Bot / Anti-Virus / Threat Emulation) Capa HTTPS Inspection habilitada (no solo Categorize HTTPS sites); Threat Prevention profile adjunto a la Access Rule correspondiente
HPE Juniper SRX "Application-First" sin SSL Forward Proxy SSL Forward Proxy + IDP + URL Filter + Sky ATP / Juniper ATP services ssl proxy profile configurado; security policy adjunta el proxy profile + IDP policy + AppFW + URL filtering
Sophos XGS Web Protection sin reglas de SSL/TLS Inspection Reglas SSL/TLS Inspection con action Decrypt and inspect + reglas IPS / AV / Application Control vinculadas Al menos una SSL/TLS Inspection rule con action Decrypt and inspect; firewall rule correspondiente referencia Web Protection + IPS + AV + Application Control
Forcepoint NGFW TLS Application Identification solamente TLS Inspection rule + Deep Inspection profile + Anti-Malware scan + URL Filtering TLS Inspection rule con Decrypt action; inline Inspection policy con Deep Inspection habilitado, Anti-Malware policy adjunta
WatchGuard Firebox HTTPS Content Inspection solamente HTTPS DPI con proxy completo + IPS + Application Control + Gateway AV + APT Blocker HTTPS proxy con Content Inspection habilitado y Inspect SNI no siendo la única action; downstream proxy actions referencian IPS, AppControl, GAV, APT Blocker
Huawei NGFW TLS visibility (sin decryption) SSL/TLS Decryption Policy + IPS profile + AV profile + URL filtering profile Rule tls-decryption-policy con action decrypt; security policy adjunta a la zone inspeccionada referencia profiles IPS / AV / URL

Cómo el bench hace enforcement en runtime

Tres capas de defensa, cada una independiente:

Capa 1 — ip-apply-<vendor>.sh rechaza configurar el modo liviano

Cada apply script por fabricante (PR-B en adelante) implementa un guard explícito que se rechaza a configurar el modo liviano cuando el Inspection Profile activo es no-minimal.

Capa 2 — ip-verify-<vendor>.sh lee el estado de la policy activa

Tras el apply exitoso, el verify script consulta la API de gestión del device para confirmar que el profile TLS/SSL adjunto a la rule activa tiene acción decrypt (no categorize / identify / mirror), y que la firewall rule correspondiente tiene el security profile group / threat prevention layer / IDP policy / DPI engine adjunto.

Si el readback muestra modo liviano, verify reprueba la ejecución antes de que los agentes sean lanzados.

Capa 3 — Anexo K del informe atestigua el modo de inspección

El Anexo K del Test Run Report (Inspection Profile Attestation, shipping en PR-D de v4.5) imprime el modo leído del device en dos momentos: tiempo de apply y tiempo de verify. Si difieren, o si alguno muestra modo liviano bajo profile no-minimal, la portada del informe marca el run como INVALID con bandera roja, y los charts de comparación en el body se rechazan a plotar el run junto con otros.

Este es el mecanismo de defensibilidad más importante del proyecto — impide que un cliente publique accidentalmente (o maliciosamente) un número que parece comparable a otros fabricantes pero es en realidad medición de modo liviano.

Por qué la trampa es tan efectiva en el campo

Tres motivos por los que clientes caen en ella sin notar:

  1. El dashboard muestra un check verde. UIs de gestión de fabricantes típicamente muestran "TLS Inspection: Enabled" en el momento en que el modo liviano se activa — no hay cue separado de UI diciendo "modo está inspeccionando solo el handshake".

  2. El throughput es gloriosamente alto. Clientes miden throughput post-deployment, ven números coincidiendo con el datasheet, y concluyen que el NGFW está performando como anunciado. La postura real de seguridad está lejos de lo que el dashboard afirma.

  3. El propio marketing del fabricante es ambiguo. Tablas de performance del datasheet a veces especifican "TLS 1.2 con AES256-SHA, RSA 2048B keys" sin decir si el payload es descifrado. Leer con atención — si no hay mención a "Application Visibility and Control" o "IPS" o "Threat Detection" en la misma línea que el número de throughput TLS, sospechar del modo liviano.

Quick-check del operador antes de cada test run

Cuando validar manualmente un setup (el preflight hará esto automáticamente cuando los scripts por-fabricante hagan ship):

  1. Abrir la UI de gestión del fabricante en la policy de TLS/SSL inspection activa.
  2. Encontrar la policy / rule que está procesando el tráfico de prueba (cross-reference con el destination subnet de la persona pool del test plan).
  3. Confirmar que la action NO está en la columna "PROHIBIDO" de la matriz arriba.
  4. Confirmar que la rule tiene el security profile group / IPS policy / DPI engine adjunto.
  5. Si la UI es ambigua (algunos fabricantes lo son), usar la CLI / API del fabricante para leer la policy verbatim y buscar las keywords de la columna "Lo que G3 busca".

Si cualquiera de estos puntos está en duda, el resultado de la prueba no es comparable a ningún otro fabricante — re-correr después de que la misconfig sea corregida.

Referencias

  • ADR 0010 amendment 2 — metodología + definiciones de las reglas G3 + G4
  • Catálogo DUT — cada modelo carga capabilities.tls_decryption_hw_accel: true|false indicando si el chassis sostiene modo DPI a line rate
  • RFC 9411 — Benchmarking Methodology for Network Security Device Performance (marzo 2023) — §6 enumera el mismo conjunto de dials, vendor-agnostic
  • Documentos de metodología NetSecOPEN — uniformemente usan terminología "TLS Inspection" y exigen modo DPI como parte del profile certified-test