Skip to content

Verificação de Modo de Decriptografia TLS

Read in your language: 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.

Status: habilitado por padrão no modo DUT desde este PR (nenhuma ação do operador é necessária além de atualizar o padrão regex no ConfigMap do probe caso o Subject da CA do vendor do seu NGFW não case com o catch-all default).

Por que isso importa

A medição principal deste test bed é o custo que o NGFW paga pela inspeção TLS — agentes (browser-engine + synthetic-load) geram carga HTTPS, o NGFW sob teste decripta e re-encripta cada conexão, e o cluster reporta o impacto em latência / throughput / taxa de erro.

Essa medição só faz sentido se o NGFW estiver de fato realizando a inspeção. Três modos de falha invalidam silenciosamente os resultados de teste:

Falha O que o operador acredita O que está acontecendo de fato
Bypass silencioso "Fizemos benchmark do NGFW com decriptografia TLS LIGADA" NGFW estava com decriptografia desabilitada → resultados medem velocidade de roteamento, não capacidade de inspeção
Bypass parcial "Todo o tráfego de teste foi decriptado" NGFW tinha uma policy excluindo uma VLAN / destino → resultados mistos (parte decriptado, parte não)
Flip durante execução "O modo de decriptografia se manteve estável durante o teste" Drift de configuração / rollback no meio de um run → resultados antes e depois não são comparáveis

Um vendor de NGFW fazendo demo do test bed tem forte incentivo para silenciosamente desabilitar a decriptografia e fazer seu equipamento parecer mais rápido. Um cliente conduzindo a própria avaliação tem forte motivo para detectar isso.

Como funciona a verificação

O cluster envia um TLS Decrypt Mode Probe dedicado e leve (k8s/dut/15-tls-decrypt-probe.yaml) que roda em paralelo com a frota de agentes. Uma vez por minuto, o probe:

  1. Abre um handshake TLS contra um webserver de persona na mesma VLAN que os agentes usam (default: shop.persona.internal:443 sobre a VLAN 20 do browser engine)
  2. Captura o certificado folha que o peer apresentou
  3. Extrai o Distinguished Name do Issuer (CN, O)
  4. Classifica o issuer:
  5. Casa com o padrão de CA do NGFW (regex configurável, default captura nomes Cisco FTD / Palo Alto / FortiGate / Check Point) → decriptografia ATIVA
  6. Casa com o Subject do persona-ca-issuer → decriptografia em BYPASS
  7. Não casa com nenhum dos dois → NÃO CLASSIFICADO (probe não consegue dizer — geralmente significa que o padrão do NGFW precisa de ajuste para o vendor em uso)
  8. Emite métricas Prometheus

O probe compartilha o mesmo network attachment dos agentes browser engine (mesmo Multus NAD dut-pw, mesma VLAN macvlan, mesmo roteamento via NGFW). O que o probe enxerga É o que os agentes enxergam — não há possibilidade de drift entre os dois.

O que isso expõe

Indicador de modo em tempo real (Grafana)

Um dashboard Grafana dedicado TLS Decrypt Mode — NGFW Inspection Verification (dashboard JSON) mostra o veredito em tempo real como um painel stat colorido:

┌──────────────────────────────────────────────────────────┐
│  Current decrypt mode      │  Peer cert issuer (CN)      │
│  ┌───────────────────┐    │  Cisco FTD CA               │
│  │  DECRYPT ACTIVE   │    │  cn=Cisco FTD CA            │
│  │  (green)          │    │  o=Cisco Systems            │
│  └───────────────────┘    │                             │
└──────────────────────────────────────────────────────────┘

Codificação por cores: - 🟢 DECRYPT ACTIVE — o NGFW está interceptando TLS conforme esperado - 🟡 DECRYPT BYPASS — o NGFW está apenas roteando, não inspecionando (resultados de teste medem velocidade de roteamento) - 🔴 UNCLASSIFIED — probe não conseguiu classificar o issuer (geralmente significa que o padrão de CA do NGFW em tls-decrypt-probe-config precisa de atualização para casar com o Subject da CA do seu vendor) - 🔴 PROBE OFFLINE — pod do probe está fora ou não reportou em > 5 min

Detecção de mudança de modo (alertas)

k8s/dut/16-tls-decrypt-rules.yaml define três alertas Prometheus:

Alerta Severidade Gatilho
TLSDecryptModeChanged warning Probe observou um flip (ON ↔ OFF) em até 10 min — dispara em até 1 min após a mudança
TLSDecryptModeUnknown warning Probe completou handshake mas o issuer não casou com nenhum padrão de CA por 3 min
TLSDecryptProbeStale warning Probe não reporta métricas frescas há > 5 min

TLSDecryptModeChanged é a killer feature: qualquer execução de teste que cubra um flip no modo de decriptografia TLS é automaticamente invalidada. A annotation diz ao operador: "Pare o run atual, confirme o estado desejado do NGFW, reinicie de forma limpa."

Por que isso é um diferenciador positivo

Appliances comerciais nessa faixa de preço — Spirent CyberFlood, Ixia BreakingPoint — não entregam esse tipo de verificação. Eles geram carga, medem throughput, mas confiam que o operador declare corretamente o estado do NGFW. Não há checagem de ground-truth.

Este test bed: - Verifica o estado do NGFW de forma independente da declaração do operador - Detecta bypass silencioso automaticamente - Expõe mudanças de modo como alertas, não enterradas em um log - Custa ~10m de CPU e ~16Mi de RAM (o probe é busybox + alpine + um sleep loop)

Isso torna os resultados de teste deste cluster defensáveis em avaliações de cliente: o operador pode apontar para o histórico do dashboard e demonstrar que o modo de decriptografia se manteve estável durante toda a janela de medição. Um vendor não consegue silenciosamente flipar o NGFW para bypass sem que isso fique visível em um painel Grafana e em um alerta.

Configuração

Edite o ConfigMap tls-decrypt-probe-config em k8s/dut/15-tls-decrypt-probe.yaml para ajustar:

Campo Default Para o que mudar
ngfw_ca_subject_pattern regex catch-all que casa com nomes comuns de vendors Um padrão específico que case com o CN/O do Subject da CA do seu NGFW. Exemplos: Cisco FTD CA, PAN Forward Trust, FGT_CA, Check Point Forward Trust. Use uma regex se você suportar múltiplos vendors de NGFW
probe_target shop.persona.internal:443 Qualquer DNS:porta de persona. Default é a primeira synthetic persona, sempre disponível
poll_interval_seconds 60 Valores menores (15–30s) para detecção mais rápida de mudança de modo, ao custo de carga ligeiramente maior do probe

Aplique a mudança de ConfigMap com kubectl apply -k k8s/dut/. A integração com Stakater Reloader reinicia o pod do probe automaticamente.

Como descobrir o Subject da CA do seu NGFW

A regex ngfw_ca_subject_pattern precisa casar com uma substring do Subject DN da CA de interceptação do seu NGFW. Para descobrir essa substring:

# 1. Probe a persona BEFORE configuring the regex (probe will return UNCLASSIFIED)
kubectl exec -n web-agents deploy/tls-decrypt-probe -c probe -- \
  /bin/sh -c "openssl s_client -connect shop.persona.internal:443 -servername shop.persona.internal -CAfile /etc/ssl/combined/ca.crt 2>/dev/null | openssl x509 -noout -issuer"

# Output (example):
# issuer=C = US, ST = California, L = San Jose, O = Cisco Systems, OU = TLS Inspection, CN = Cisco FTD Forward Trust CA

# 2. Extract a unique substring — for the example above, "Cisco FTD" is plenty.
# 3. Update the ConfigMap:
kubectl edit configmap tls-decrypt-probe-config -n web-agents
#   ngfw_ca_subject_pattern: "Cisco FTD"

# 4. Probe will pick up the new pattern within ~30s and reclassify the cert as ACTIVE.

Relacionados