Skip to content

Armadilhas de TLS Inspection — matriz de enforcement por fabricante

Leia no seu idioma: English · Português · Español

Status do escopo (pós-congelamento de escopo 2026-05-10) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Resumo

Vários fabricantes de NGFW expõem dois modos distintos para o que chamam genericamente de "SSL Inspection" ou "TLS Inspection". Um inspeciona somente o handshake (barato, rápido, inútil para ameaças no payload); o outro executa MITM completo + DPI no payload descriptografado (o único modo que vale medir).

Alguns fabricantes publicam números de performance no modo leve sem explicitar a distinção. Números medidos no modo leve são tipicamente 5-10× maiores que os números reais de TLS Inspection + DPI — e o cliente comparando entre fabricantes recebe uma comparação enganosa de banana com maçã.

Este documento é a referência de enforcement para os scripts apply por-fabricante (scripts/ip-apply-<vendor>.sh) e para o operador que precisa saber o que olhar ao validar um setup. A metodologia canônica está em ADR 0010 amendment 2 (regra G3: TLS Inspection sem DPI não é modo de teste válido).

A matriz de armadilhas

Cada fabricante no catálogo de DUT embala o modo leve vs completo com nomes diferentes. Os scripts de apply OBRIGATORIAMENTE selecionam o modo completo quando o Inspection Profile ativo é não-minimal, e OBRIGATORIAMENTE falham loud se forem instruídos a configurar o modo leve.

Fabricante Modo leve (PROIBIDO pela G3) Modo DPI completo (EXIGIDO pela G3) O que a G3 procura no readback do device
Fortinet FortiGate "Certificate Inspection" "Deep Inspection" Profile ssl-ssh-profile com inspect-all enable e ao menos um de https-policy, ftps-policy, imaps-policy setado para deep-inspection
Cisco FTD (FMC / FDM / SCC) TLS Server Identity Discovery apenas Ação "Decrypt - Resign" com policies de AVC + IPS + Malware + URL anexadas SSL Policy na Access Control Policy com ao menos uma rule com ação Decrypt - Resign, E a regra Access Control correspondente tem Intrusion + File + URL policies anexadas
Palo Alto PAN-OS "Decrypt - No Profile" / "Mirror" apenas Ação "Decrypt" com Decryption Profile anexado + Security Policy com Vulnerability + Anti-Spyware + URL Filtering + WildFire profiles Decryption Policy rule com action decrypt, Decryption Profile anexado tem block-unsupported-version, block-unknown-cert; Security Policy correspondente tem Security Profile Group
Check Point Quantum / Force HTTPS Categorization apenas HTTPS Inspection (Inbound + Outbound) + camada de Threat Prevention (IPS / Anti-Bot / Anti-Virus / Threat Emulation) Camada HTTPS Inspection ativa (não só Categorize HTTPS sites); Threat Prevention profile anexado à Access Rule correspondente
HPE Juniper SRX "Application-First" sem SSL Forward Proxy SSL Forward Proxy + IDP + URL Filter + Sky ATP / Juniper ATP services ssl proxy profile configurado; security policy anexa o proxy profile + IDP policy + AppFW + URL filtering
Sophos XGS Web Protection sem rules de SSL/TLS Inspection Rules SSL/TLS Inspection com action Decrypt and inspect + rules de IPS / AV / Application Control linkadas Ao menos uma SSL/TLS Inspection rule com action Decrypt and inspect; firewall rule correspondente referencia Web Protection + IPS + AV + Application Control
Forcepoint NGFW TLS Application Identification apenas TLS Inspection rule + Deep Inspection profile + Anti-Malware scan + URL Filtering TLS Inspection rule com Decrypt action; inline Inspection policy com Deep Inspection ativa, Anti-Malware policy anexada
WatchGuard Firebox HTTPS Content Inspection apenas HTTPS DPI com proxy completo + IPS + Application Control + Gateway AV + APT Blocker HTTPS proxy com Content Inspection ativo e Inspect SNI não sendo a única action; downstream proxy actions referenciam IPS, AppControl, GAV, APT Blocker
Huawei NGFW TLS visibility (sem decryption) SSL/TLS Decryption Policy + IPS profile + AV profile + URL filtering profile Rule tls-decryption-policy com action decrypt; security policy anexada à zone inspecionada referencia profiles de IPS / AV / URL

Como o bench faz enforcement em runtime

Três camadas de defesa, cada uma independente:

Camada 1 — ip-apply-<vendor>.sh recusa configurar o modo leve

Cada apply script por fabricante (PR-B em diante) implementa um guard explícito que se recusa a configurar o modo leve quando a Inspection Profile ativa é não-minimal.

Camada 2 — ip-verify-<vendor>.sh lê o estado da policy ativa

Após o apply ter sucesso, o verify script consulta a API de gerência do device para confirmar que o profile TLS/SSL anexado à rule ativa tem ação decrypt (não categorize / identify / mirror), e que a firewall rule correspondente tem o security profile group / threat prevention layer / IDP policy / DPI engine anexado.

Se o readback mostrar modo leve, o verify reprova a execução antes dos agentes serem lançados.

Camada 3 — Anexo K do report atesta o modo de inspeção

O Anexo K do Test Run Report (Inspection Profile Attestation, shipping em PR-D do v4.5) imprime o modo lido do device em dois momentos: tempo de apply e tempo de verify. Se eles divergirem, ou se algum mostrar modo leve sob profile não-minimal, a capa do report marca o run como INVALID com bandeira vermelha, e os charts de comparação no body se recusam a plotar o run junto com outros.

Esse é o mecanismo de defensibilidade mais importante do projeto — impede que um cliente publique acidentalmente (ou maliciosamente) um número que parece comparável a outros fabricantes mas é na verdade medição de modo leve.

Por que a armadilha é tão eficaz no campo

Três motivos pelos quais clientes caem nela sem perceber:

  1. O dashboard mostra um check verde. UIs de gerência de fabricantes tipicamente exibem "TLS Inspection: Enabled" no momento em que o modo leve é ligado — não há cue separado de UI dizendo "modo está inspecionando só o handshake".

  2. O throughput é gloriosamente alto. Clientes medem throughput pós-deployment, veem números batendo o datasheet, e concluem que o NGFW está performando como anunciado. A postura real de segurança está longe do que o dashboard afirma.

  3. O próprio marketing do fabricante é ambíguo. Tabelas de performance do datasheet às vezes especificam "TLS 1.2 com AES256-SHA, RSA 2048B keys" sem dizer se o payload é descriptografado. Leia com atenção — se não houver menção a "Application Visibility and Control" ou "IPS" ou "Threat Detection" na mesma linha que o número de throughput TLS, suspeite do modo leve.

Quick-check do operador antes de cada test run

Quando validar manualmente um setup (o preflight fará isso automaticamente quando os scripts por-fabricante shippearem):

  1. Abra a UI de gerência do fabricante na policy de TLS/SSL inspection ativa.
  2. Encontre a policy / rule que está processando o tráfego de teste (cross-reference com o destination subnet da persona pool do test plan).
  3. Confirme que a action NÃO está na coluna "PROIBIDO" da matriz acima.
  4. Confirme que a rule tem o security profile group / IPS policy / DPI engine anexado.
  5. Se a UI for ambígua (alguns fabricantes são), use a CLI / API do fabricante para ler a policy verbatim e procurar pelas keywords da coluna "O que a G3 procura".

Se qualquer um destes pontos estiver em dúvida, o resultado do teste não é comparável a nenhum outro fabricante — refaça depois que a misconfig for corrigida.

Referências

  • ADR 0010 amendment 2 — metodologia + definições das regras G3 + G4
  • Catálogo DUT — cada modelo carrega capabilities.tls_decryption_hw_accel: true|false indicando se o chassis sustenta modo DPI a line rate
  • RFC 9411 — Benchmarking Methodology for Network Security Device Performance (março 2023) — §6 enumera o mesmo conjunto de dials, vendor-agnostic
  • Documentos de metodologia NetSecOPEN — uniformemente usam terminologia "TLS Inspection" e exigem modo DPI como parte do profile certified-test