Skip to content

TLSStress.Art — Para que serve

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

Estado do escopo (pós-Scope-Freeze 2026-05-10) — Veja ARCHITECTURE.md para a arquitetura canônica de 37 MÓDULOs + 7 Test Kinds + DOM/CPOS/PIE-PA de segurança. ADRs 0014, 0019-0025 cobrem adições pós-Freeze. Web Agent Cluster for NGFW TLS Inspection performance test — bancada de testes open-source para medir a capacidade real de inspeção TLS de Next-Generation Firewalls (NGFWs) sob carga HTTP/2 e HTTP/3.

Autor: André Luiz Gallon · Licença: PolyForm Noncommercial 1.0.0 + Appendix A · Público-alvo: o licenciante e os parceiros autorizados pelo licenciante

1. Por que este software existe

Quando uma empresa precisa testar a capacidade de inspeção TLS de um firewall corporativo, o mercado tem dois extremos:

Categoria Exemplos Limitação
Ferramentas gratuitas TRex, iPerf3, wrk, Locust Não geram tráfego TLS realista em escala — pacotes crus ou HTTP simples, sem JavaScript, sem handshake TLS completo, sem HTTP/3
Appliances comerciais Spirent CyberFlood, Ixia BreakingPoint, IXIA IxLoad US$ 50K–500K por chassi; hardware proprietário; difícil de automatizar em CI/CD
TLSStress.Art Este projeto (open-source, PolyForm Noncommercial) Roda em hardware commodity (Ubuntu + k3s); navegador real (browser engine) + carga sintética (k6); HTTP/2 e HTTP/3 nativos; sem custo de licença para o público elegível

TLSStress.Art preenche essa lacuna: oferece teste de inspeção TLS com realismo de nível de produção — navegadores reais, JavaScript, cookies, certificados válidos — sem custo de licença e com automação completa via Kubernetes e GitHub Actions.

A pergunta que o produto responde: quantas conexões TLS simultâneas o firewall consegue lidar antes que o desempenho degrade — e qual é o impacto comparativo entre HTTP/2 e HTTP/3?

2. Como funciona — visão de 30 segundos

┌─────────────────────────┐
│ Load robots             │  browser engine (real browser) + k6 (HTTP)
│ up to 300 PW + 1000 synthetic-load engine  │  generate TLS traffic against the personas
└──────────┬──────────────┘
           │ Leg 1: encrypted HTTPS (robots trust the firewall cert)
           ▼
┌─────────────────────────┐
│ FIREWALL (DUT)          │  Appliance under test — decrypts, inspects,
│ — under test, measured  │  re-encrypts every packet
└──────────┬──────────────┘
           │ Leg 2: re-encrypted HTTPS (firewall talks to persona)
           ▼
┌─────────────────────────┐
│ 30 Caddy personas       │  20 Synthetic (always-on) + 10 Cloned slots
│ 20 Synthetic + 10       │  (operator picks public sites to clone)
│ Cloned slots            │
└─────────────────────────┘

         ┌─── Telemetry collected in parallel (4 pillars) ─────┐
         ▼                                                     ▼
   SNMP exporter        Promtail/Loki          DUT API REST       OpenTelemetry → Tempo
   (CPU/mem/IF of       (events from Nexus,    (config + state    (distributed tracing
    Nexus + DUT)         NGFW, UCS hosts)       of FTD/Nexus/      opt-in in agents)
                                                UCS/Fortinet)

Leg 1 — robôs abrem conexões HTTPS para os endereços das personas. O firewall intercepta e apresenta seu próprio certificado (o operador configura os agentes para confiar em ngfw-ca).

Leg 2 — o firewall abre uma segunda conexão HTTPS para a persona de destino. O certificado é emitido pelo cert-manager (CA persona-ca).

4 pilares de telemetria coletam evidência simultaneamente — métricas (Prometheus + SNMP), eventos (correlação de syslog via Loki), estado do dispositivo (DUT API REST) e traces (Tempo) — respondendo não apenas "qual foi o p99" mas também "o que aconteceu no DUT quando o p99 disparou".

3. As 30 personas

A frota de personas é dividida em dois grupos:

20 Synthetic (always-on)

Definidas em personas.yaml, geradas a partir de templates Caddy. Cada persona roda em um namespace Kubernetes dedicado, com certificado TLS, IP fixo, VLAN exclusiva (101–120) e entrada DNS dedicada.

Distribuídas em 4 arquétipos:

Arquétipo Exemplos Como o tráfego é gerado
skin CDN, blog, portal, news, gov, edu, gallery, stream, download, docs HTML/CSS/JS sintético; assets estáticos de alto throughput
mock api-rest, api-graphql, chat, webhook, telemetry, ads JSON/XML configurável via YAML; simula microsserviços
har-replay har-saas, har-social, har-webmail, har-media Replay de gravações HAR (HTTP Archive) de sessões reais
real-app shop (Saleor, e-commerce completo) Aplicação real com banco de dados, estado, JavaScript dinâmico

10 Cloned slots (preenchidos pelo operador)

VLANs 200–209. O operador escolhe um site público (ex.: globo.com, cnn.com), o Cloner faz crawl + snapshot do conteúdo estático e a réplica passa a servir localmente como uma persona "real" em *.persona.internal.

O Cloner usa três interfaces de rede distintas: OOBI (mgmt), VLAN 40 (DHCP do ISP do cliente, para baixar conteúdo da Internet pública) e uma VLAN macvlan dentro do cluster (para servir conteúdo clonado às demais personas/agentes).

4. Os 4 pilares de telemetria

O produto não mede apenas latência. Para responder por que uma métrica mudou — pré-requisito para que um teste NGFW seja válido — coletamos evidência de quatro fontes simultaneamente:

Pilar Fonte O que captura Endpoint
1. Métricas (SNMP + Caddy + agentes) SNMP exporter, Caddy /metrics, browser-engine/synthetic-load CPU, memória e contadores de interface do switch e do firewall; req/s, bytes, conexões ativas, QUIC vs TCP nas personas; latência, throughput, taxa de erro, handshake TLS nos agentes Prometheus → Grafana
2. Eventos (correlação Syslog) Promtail (NodePort 30514) → Loki Eventos do Nexus 9000, do NGFW DUT, dos hosts UCS. Política OOBI-only (NUNCA no data plane). Ingestão é imposta por dois recursos NetworkPolicy em nível de cluster Loki → Grafana Explore + dashboard "Syslog Correlation"
3. Estado do DUT (REST API) Worker de polling no pod Dashboard Para cada DUT registrado: versão, config NTP, política de inspeção SSL/TLS, estado de HA, vizinhos LLDP/CDP, inventário de hardware. Snapshots assinados com SHA-256 (cadeia de custódia forense) DUT API REST adapters (FTD, Nexus, UCS, Fortinet) → Postgres dut_api_snapshots
4. Traces (OpenTelemetry → Tempo) SDK opt-in em browser-engine + synthetic-load Distributed tracing por ciclo de teste, com spans para cada handshake TLS. Cobre o caminho ponta-a-ponta: agente → NGFW → persona Tempo → Grafana → Dashboard

A combinação dos quatro permite respostas como: "latência p99 disparou às 14:23 → confirmado no syslog: NGFW logou CPU alta às 14:22 → confirmado na DUT API: política de decryption foi alterada por outro operador 4 minutos antes → trace mostra handshake levando 380ms vs baseline de 95ms".

5. DUT API — integração multi-vendor

Padrão adapter com 4 vendors entregues (Palo Alto no roadmap):

Vendor Adapter Auth Status
Cisco FTD (FDM-managed) cisco-ftd.ts OAuth2 → Bearer ✅ Entregue
Cisco Nexus 9000 cisco-nexus.ts NX-API cookie (APIC-cookie) ✅ Entregue
Cisco UCS C-Series CIMC cisco-ucs-cimc.ts Basic Auth (Redfish) ✅ Entregue
Fortinet FortiGate fortinet-fortigate.ts API key Bearer (FortiOS REST v2) ✅ Entregue
Palo Alto (PAN-OS) — API key (XML API) 📋 Roadmap

Fluxo do operador: 1. UI em /admin/dut-api registra um dispositivo (URL, credenciais — criptografadas com AES-256-GCM) 2. Worker de polling no Dashboard coleta snapshots a cada N minutos (configurável; padrão 5min) 3. Cada snapshot vira uma linha em dut_api_snapshots com payload JSON + SHA-256 da forma canônica 4. Snapshots aparecem em dashboards Grafana ("DUT Live State") e (no roadmap) nos Anexos B/C/D do Test Run Report

Catálogo de 45 features mapeado por vendor — qual adapter expõe config NTP, qual expõe estado HA, etc. — em docs/API_FEATURE_CATALOG.{md,pt-BR,es}.md.

6. Test Plans + Test Run Reports

Test Plan engine — 15 planos pré-configurados (catálogo em docs/TEST_PLANS.{md,pt-BR,es}.md): - Identificadores estáveis (string ID, não hash) para comparações entre engagements - Validados por schema Zod, sincronizados ao Postgres no boot - Cada plano declara o estado NGFW esperado (ex.: ngfw_state_required: decryption-on) - Os planos cobrem: baseline H2/H3, max-CPS handshake, throughput sustentado, decryption-on vs decryption-off, falhas de cert, protocolo misto, etc.

Test Run Report — Fase 1 entregue (#185): - HTML print-styled (/runs/{id}/report) com capa, página de licença em 3 idiomas, resumo executivo, config do plano, anexos placeholder - Rodapé de licença fixado em cada página - Hashes SHA-256 do relatório completo + plan-snapshot + por-anexo (cadeia forense) - API JSON paralela: /api/test-runs/{id}/report.json

Roadmap das fases pendentes: - Fase 2 — render server-side com Puppeteer → PDF real (atualmente HTML print) - Fase 3 — Anexos B/C/D conectados (snapshots Nexus/NGFW/UCS embutidos no relatório) - Fase 4 — assinatura Cosign + entrada Rekor/Sigstore (log de transparência público) - Fase 5 — comparação N-runs (run A vs run B), rollups de tendência (semanal/mensal), replay de snapshot

7. Pre-flight, time-sync, validade do test bed

Pre-flight checks (engine + catálogo de 5) — antes de cada run, valida o estado do lab: - ngfw-deploy-clean — nenhum deploy pendente no DUT - ngfw-decrypt-state-matches-plan — estado de decryption alinhado com o plano - ntp-source-configured — todo componente tem NTP definido - ngfw-ha-state-sane — par HA em estado consistente - snapshot-fresh — última coleta DUT API < threshold

Camada time-sync — relógio de todo o lab sincronizado: - Script scripts/check-time-sync.sh mede skew entre componentes; alertas Prometheus disparam acima do threshold - O Cloner pode atuar como NTP relay (stratum-2) quando a Internet do data center é restrita - Browser-clock fallback documentado e implementado: a UI admin em /admin/time-sync envia o horário do laptop do operador via POST /api/time-sync/set-from-browser (com acknowledgement: NOT_FORENSIC obrigatório), retorna o comando kubectl chronyc settime para o operador aplicar manualmente. O audit log marca forensic_grade: false automaticamente.

Prova de validade do test-bed — evolução de observabilidade em 4 fases entregues: 1. Thresholds deployment-aware + fleet readiness (PR-1+2, #173) — alertas que sabem qual deploy mode (single/dual/tri/multi) está ativo 2. Correlação causal topology-aware (PR-3, #177) — correlaciona métricas pelos nós/personas/agentes que de fato se comunicam entre si 3. SLO + alertas multi-window multi-burn-rate + detecção de anomalia + Tempo (PR-4, #179) 4. Banner de licença sempre visível em Dashboard, Grafana, Prometheus (#178)

8. Compliance, forense, proteção de IP

Marca registrada e tagline oficial: - Nome: TLSStress.Art (™ — registro em andamento) - Tagline: Web Agent Cluster for NGFW TLS Inspection performance test

Licença: PolyForm Noncommercial 1.0.0 + Appendix A — uso somente não-comercial, e o Appendix A restringe o público elegível ao licenciante (e ao pessoal que ele autoriza) e aos engenheiros pré-/pós-vendas dos parceiros comerciais certificados ou autorizados pelo licenciante. Detalhes em LICENSE e USAGE_POLICY.md.

License Acceptance Modal — o primeiro login no Dashboard intercepta o operador com um modal exigindo aceite da licença + USAGE_POLICY. O aceite grava uma linha em audit_log (visível em /admin/audit/license-acceptances). Política de privacidade em PRIVACY_POLICY.md, política de auditoria em AUDIT_LOG.md.

Infraestrutura forense (IP_PROTECTION.md): - FINGERPRINT_REGISTRY em branch privado (private/forensic) — fingerprints intencionais no código que comprovam autoria caso surja um clone - Asset hashes manifest assinado a cada release - Tamper-check workflow roda em PRs e em main, comparando hashes contra o manifest - Roadmap: migrar FINGERPRINT_REGISTRY para um repo separado para evitar vazamento via Access Broker

TLS Decrypt Mode Verification (#180) — probe que cruza o issuer-cert observado na conexão contra a política de decryption esperada do plano. Garante que a medição reflete o modo operacional real do NGFW (sem esperar pelos logs do dispositivo).

9. Onboarding do operador

Cinco docs encadeados para levar um operador do zero ao primeiro run:

Access Request   →   Clone   →   Install (Runbook)
[ACCESS_REQUEST]     [CLONE_FOR_INSTALL]   [RUNBOOK_FIRST_INSTALL]
                                              │
                                              └── alternate: [AIRGAP_INSTALL]

Maintainer-only setup (one-time): [PRIVATE_REPO_SETUP]
  • Access Broker (ACCESS_REQUEST.md) — template de issue + GitHub Action /approve /deny. Auto-list de domínios controlados pelo licenciante; fluxo manual com partner ID para os parceiros autorizados pelo licenciante.
  • Clone (CLONE_FOR_INSTALL.md) — 4 opções de git clone autenticado (HTTPS+PAT, SSH key, GitHub CLI, tarball assinado).
  • Runbook First Install (RUNBOOK_FIRST_INSTALL.md) — protocolo de 4 passos: lab→DUT→smoke→measure. Time budget: ~2h.
  • Instalação airgap (AIRGAP_INSTALL.md) — alternativa para data centers sem Internet (regulamentado / classificado).
  • Private repo setup (PRIVATE_REPO_SETUP.md) — setup maintainer-only (uma vez, pelo dono do repo).

10. Tuning aplicado em cada camada

Para que os resultados reflitam o limite real do firewall — não limitações do test bed — cada componente da plataforma foi tunado com parâmetros específicos. Scripts automatizados aplicam o tuning de forma reproduzível.

Componente Parâmetros Impacto
Linux Ubuntu host (DaemonSet node-tuning) rmem_max/wmem_max = 64 MB; TCP BBR + FQ; tcp_max_syn_backlog=65535; vm.swappiness=5; CPU governor performance; THP madvise; nf_conntrack_max=2M; tcp_orphan_retries=2 Crítico para QUIC/HTTP3: buffers UDP grandes evitam drops; BBR melhora throughput em redes com variação de RTT
Caddy webserver (por pod persona) GOMAXPROCS via resourceFieldRef; GOMEMLIMIT=460MiB; GOGC=200; QoS Guaranteed (CPU 2/2, Mem 512Mi/512Mi) Go usa todos os cores disponíveis sem over-commit; GC menos frequente reduz tail latency
Switch Nexus 9000 (script automatizado) EEE off, flow control off, MTU 9216 (jumbo frames), QoS DSCP AF41, hash ECMP com porta UDP, ARP timeout 300s Jumbo frames aumentam throughput; EEE desabilitado elimina latência adicionada; ECMP com porta UDP distribui QUIC corretamente
agentes browser-engine + synthetic-load NODE_EXTRA_CA_CERTS / SSL_CERT_FILE apontando para persona-ca; GOMAXPROCS/GOMEMLIMIT no k6; resources right-sized; topology spread; CYCLE_CONCURRENCY=3 Confiança nos certs sem warnings; UDP 443 aberto; ocupação máxima de cores sem conflito

Guias detalhados: docs/PERFORMANCE_TUNING_HOST.md, docs/NEXUS9K_TUNING.md, além dos artefatos k8s/85-node-tuning.yaml + scripts/nexus/0[1-3]-*.nxos.

A configuração completa foi desenhada para ser low-friction: ./scripts/k8s-dut-up.sh up sobe toda a plataforma em fases automáticas.

11. Arquitetura de rede

Ubuntu Server (k3s)
├── eth0       →  OOBI network  (mgmt, metrics, dashboard, control, Service VIPs)
└── eth1       →  Nexus 9000 trunk  (data VLANs)
               ├── VLAN 20  (172.16.0.0/16)   →  browser-engine agents  (dut-pw)
               ├── VLAN 30  (172.17.0.0/16)   →  synthetic-load agents          (dut-k6)
               ├── VLAN 40  (DHCP from ISP)   →  Cloner ISP egress  (Internet uplink, outside our scheme)
               ├── VLAN 99  (192.168.90.0/24) →  OOBI mgmt          (dut-mgmt, SNMP, syslog, NTP)
               │
               │   20 Synthetic VLANs (101–120) — one per Caddy persona:
               ├── VLAN 101–120  (10.1.x.0/27)  →  shop, news, blog, docs, gallery, stream, download,
               │                                   edu, gov, cdn, api-rest, api-graphql, chat, webhook,
               │                                   telemetry, ads, har-saas, har-social, har-webmail, har-media
               │
               │   10 Cloned VLANs (200–209) — dynamic slots filled by the Cloner:
               └── VLAN 200–209  (10.2.x.0/27)  →  cloned-1 .. cloned-10
                               │
                        FIREWALL (DUT) ←── inspects TLS on all VLANs
                               │
                        4 telemetry pillars collect evidence in parallel
                        (SNMP + Syslog + DUT API + Tempo)

Por que separação estrita entre OOBI ↔ data plane? - O data plane (VLANs 20, 30, 40, 101–120, 200–209) carrega o tráfego de teste. Qualquer tráfego de mgmt aqui contamina métricas por ciclo. - A OOBI (VLAN 99 / 192.168.90.0/24) é exclusiva para mgmt — Prometheus scrape, SNMP, syslog, NTP, kubectl, dashboard. As políticas syslog-oobi-only + syslog-deny-data-plane são impostas em nível de cluster por dois recursos NetworkPolicy complementares. - Service VIPs na OOBI (.50–.69) — Promtail :514, NTP relay :123, Dashboard :3000, Prometheus :9090, Grafana :3001, Loki :3100, SNMP-Exporter, Alertmanager, Tempo. Dispositivos DUT apontam para IPs fixos, não para NodePorts em um UCS específico.

12. 4 modos de deployment

Modo Quando usar Guia
Single-node (1 UCS) Avaliação inicial; hardware limitado UBUNTU_K3S_SINGLENODE
Dual-node (2 UCS) UCS-1 = agentes; UCS-2 = personas + serviços + observabilidade UBUNTU_K3S_DUALNODE
Tri-node (3 UCS) UCS-1 = só browser engine; UCS-2 = só k6; UCS-3 = personas + serviços + obs UBUNTU_K3S_TRINODE
Multi-node (4 UCS dedicados) UCS-1 = 30 personas · UCS-2 = browser engine · UCS-3 = k6 · UCS-4 = Dashboard/Postgres/Grafana/Cloner. Throughput máximo, sem contenção UBUNTU_K3S_MULTINODE

Os modos dual/tri/multi usam overlays Kustomize sob overlays/{dual-node,tri-node,multi-node}/ que aplicam nodeSelector a cada Deployment/StatefulSet. Permitem escalar browser engine até 300 instâncias e k6 até 1.000 instâncias sem compartilhar CPU/memória com os webservers das personas.

13. Dashboard operacional

Cockpit web (Next.js) em /. Páginas principais:

  • Overview — status das 30 personas em tempo real (running, paused, error)
  • Personas individuais — start/pause/deprovision; configurar rotas de resposta da mock-persona (YAML inline via API)
  • /admin/dut-api — registrar dispositivos DUT, testar conectividade, disparar snapshot, rodar pre-flight
  • /admin/time-sync — UI admin para o fluxo de browser-clock fallback (com acknowledgement NOT_FORENSIC obrigatório)
  • /admin/audit/license-acceptances — visualizador dos aceites de licença (auditoria forense)
  • Test Plans — escolher um plano, disparar um run, monitorar progresso
  • Test Runs — histórico, link para HTML report (Fase 1)
  • Métricas Grafana — embutidas por persona e por protocolo (HTTP/2 vs HTTP/3 vs HTTP/3-fallback-TCP)

Resumo em uma frase

TLSStress.Art é uma bancada de testes open-source (PolyForm Noncommercial, público restrito ao licenciante) que preenche a lacuna entre ferramentas gratuitas sem escala (TRex, iPerf) e appliances comerciais que custam até US$ 500K (Spirent, Ixia) — simulando até 30 sites realistas (20 Synthetic + 10 slots Cloned pelo operador) com browser-engine/synthetic-load contra o NGFW sob teste, integrando 4 pilares de telemetria (SNMP de hardware + correlação de syslog + DUT API REST multi-vendor para FTD/Nexus/UCS/Fortinet + tracing OpenTelemetry), com 15 planos de teste pré-configurados, Test Run Reports HTML/PDF assinados forensicamente, License Acceptance Modal + audit log + tamper-check, e tudo tunado do host Linux ao switch Nexus para que o gargalo medido seja sempre o NGFW — nunca o test bed.