Skip to content

Verificación de Modo de Descifrado TLS

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.

Estado: habilitado por defecto en modo DUT desde este PR (no se requiere acción del operador más allá de actualizar el patrón regex en el ConfigMap del probe si el Subject de la CA del vendor de tu NGFW no coincide con el catch-all por defecto).

Por qué esto importa

La medición principal de este test bed es el costo que paga el NGFW por la inspección TLS — los agentes (browser-engine + synthetic-load) generan carga HTTPS, el NGFW bajo prueba descifra y vuelve a cifrar cada conexión, y el cluster reporta el impacto en latencia / throughput / tasa de errores.

Esa medición solo tiene sentido si el NGFW está realmente realizando la inspección. Tres modos de falla invalidan silenciosamente los resultados de prueba:

Falla Lo que el operador cree Lo que realmente está pasando
Bypass silencioso "Hicimos benchmark del NGFW con descifrado TLS ON" El NGFW tenía descifrado deshabilitado → los resultados miden velocidad de routing, no capacidad de inspección
Bypass parcial "Todo el tráfico de prueba fue descifrado" El NGFW tenía una política excluyendo una VLAN / destino → resultados mixtos (algunos descifrados, otros no)
Flip durante ejecución "El modo de descifrado se mantuvo estable durante la prueba" Drift de configuración / rollback en medio de un run → los resultados antes y después no son comparables

Un vendor de NGFW haciendo demo del test bed tiene un fuerte incentivo para deshabilitar silenciosamente el descifrado y hacer que su dispositivo se vea más rápido. Un cliente ejecutando su propia evaluación tiene una fuerte razón para detectar eso.

Cómo funciona la verificación

El cluster incluye un TLS Decrypt Mode Probe dedicado y liviano (k8s/dut/15-tls-decrypt-probe.yaml) que corre junto al fleet de agentes. Una vez por minuto, el probe:

  1. Abre un handshake TLS hacia un webserver persona en la misma VLAN que usan los agentes (por defecto: shop.persona.internal:443 sobre la VLAN 20 de browser engine)
  2. Captura el certificado hoja que el peer presentó
  3. Extrae el Distinguished Name del Issuer (CN, O)
  4. Clasifica el issuer:
  5. Coincide con el patrón de la CA del NGFW (regex configurable, por defecto captura nombres de Cisco FTD / Palo Alto / FortiGate / Check Point) → descifrado ACTIVE
  6. Coincide con el Subject del persona-ca-issuer → descifrado BYPASS
  7. No coincide con ninguno → UNCLASSIFIED (el probe no puede determinar — usualmente significa que el patrón del NGFW necesita ajuste para el vendor en uso)
  8. Emite métricas Prometheus

El probe comparte el mismo network attachment que los agentes browser engine (mismo NAD Multus dut-pw, misma VLAN macvlan, mismo routing a través del NGFW). Lo que el probe ve ES lo que los agentes ven — no hay drift posible entre los dos.

Qué expone esto

Indicador de modo en tiempo real (Grafana)

Un dashboard Grafana dedicado TLS Decrypt Mode — NGFW Inspection Verification (dashboard JSON) muestra el veredicto en tiempo real como un panel de stat coloreado:

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

Codificación de colores: - 🟢 DECRYPT ACTIVE — el NGFW está interceptando TLS como se espera - 🟡 DECRYPT BYPASS — el NGFW solo está enrutando, no inspeccionando (los resultados de prueba miden velocidad de routing) - 🔴 UNCLASSIFIED — el probe no pudo clasificar el issuer (usualmente significa que el patrón de la CA del NGFW en tls-decrypt-probe-config necesita una actualización para coincidir con el Subject de la CA de tu vendor) - 🔴 PROBE OFFLINE — el pod del probe está caído o no ha reportado en > 5 min

Detección de cambio de modo (alertas)

k8s/dut/16-tls-decrypt-rules.yaml define tres alertas Prometheus:

Alerta Severidad Disparador
TLSDecryptModeChanged warning El probe observó un flip (ON ↔ OFF) dentro de 10 min — dispara dentro de 1 min del cambio
TLSDecryptModeUnknown warning El probe completó el handshake pero el issuer no coincidió con ningún patrón de CA durante 3 min
TLSDecryptProbeStale warning El probe no ha reportado métricas frescas en > 5 min

TLSDecryptModeChanged es la killer feature: cualquier run de prueba que abarque un flip en el modo de descifrado TLS es invalidado automáticamente. La anotación le dice al operador: "Detén el run actual, confirma el estado deseado del NGFW, reinicia limpiamente."

Por qué esto es un diferenciador positivo

Los appliances comerciales en este rango de precio — Spirent CyberFlood, Ixia BreakingPoint — no incluyen este tipo de verificación. Generan carga, miden throughput, pero confían en que el operador declare correctamente el estado del NGFW. No hay verificación de ground-truth.

Este test bed: - Verifica el estado del NGFW independientemente de la declaración del operador - Detecta bypass silencioso automáticamente - Surfacea los cambios de modo como alertas, no enterrados en un log - Cuesta ~10m de CPU y ~16Mi de RAM (el probe es busybox + alpine + un sleep loop)

Eso hace que los resultados de prueba de este cluster sean defendibles en evaluaciones de clientes: el operador puede señalar el historial del dashboard y demostrar que el modo de descifrado se mantuvo estable durante toda la ventana de medición. Un vendor no puede hacer flip silencioso del NGFW a bypass sin que sea visible en un panel Grafana y una alerta.

Configuración

Edita el ConfigMap tls-decrypt-probe-config en k8s/dut/15-tls-decrypt-probe.yaml para ajustar:

Campo Por defecto Qué cambiar
ngfw_ca_subject_pattern regex catch-all que coincide con nombres comunes de vendors Un patrón específico que coincida con el CN/O del Subject de la CA de tu NGFW. Ejemplos: Cisco FTD CA, PAN Forward Trust, FGT_CA, Check Point Forward Trust. Usa un regex si soportas múltiples vendors de NGFW
probe_target shop.persona.internal:443 Cualquier DNS:port de persona. Por defecto la primera persona sintética, siempre disponible
poll_interval_seconds 60 Valores más pequeños (15–30s) para detección más rápida de cambio de modo a costa de algo más de carga del probe

Aplica el cambio del ConfigMap con kubectl apply -k k8s/dut/. La integración con Stakater Reloader reinicia el pod del probe automáticamente.

Cómo encontrar el Subject de la CA de tu NGFW

El regex ngfw_ca_subject_pattern debe coincidir con un substring del DN del Subject de la CA de interceptación de tu NGFW. Para encontrar ese 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.

Relacionado