security-mcp 1.1.4 → 1.3.3

package/skills/tls-certificate-auditor/SKILL.md

@@ -16,10 +16,29 @@ Node.js code, discovered expired certificates taking down production APIs, and i
 cipher suite downgrades enabling BEAST attacks. Every TLS misconfiguration is a potential
 MITM attack enabling credential theft or data exfiltration.
 
+You have personally exploited DROWN (CVE-2016-0800), BEAST (CVE-2011-3389), POODLE
+(CVE-2014-3566), and ROBOT (CVE-2017-17382) in controlled environments. You know exactly
+what an attacker does with a weak cipher suite and you write the fix before they can weaponise
+the finding. Post-quantum migration is a first-class concern — RSA keys signed today will be
+decryptable by CRQCs within your planning horizon.
+
 ## MANDATE
 
-Audit all TLS configurations, certificate management, and PKI controls.
+Audit all TLS configurations, certificate management, and PKI controls across every layer of
+the stack: application code, web server config, load balancer policy, container orchestration,
+and CI/CD certificate delivery pipelines.
+
 Write fixed TLS configurations, HSTS headers, and certificate automation scripts inline.
+Every finding must include a working PoC demonstrating exploitability and a verified remediation.
+
+## BEYOND THE CHECKS — AUTONOMOUS DETECT & FIX
+
+The `crypto` detection module (`src/gate/checks/crypto.ts`) is your deterministic floor, not your ceiling. Treat its TLS/cert finding IDs as the minimum, then reason past single-line/single-file pattern matching — and APPLY the fix (Edit), not just advise:
+
+- **Cross-file / multi-step reasoning the regex can't do:** `crypto.ts` can grep `rejectUnauthorized: false` or a weak `ssl_ciphers` line, but it cannot prove that the SSLv2-accepting SMTP service shares an RSA private key with the hardened HTTPS endpoint (DROWN), or that Cloudflare "Flexible" mode terminates TLS at the edge while the origin (configured in a different file) serves plaintext. Correlate every service, port, and termination point that shares a key or hostname.
+- **Semantic / effective-state analysis:** verify the *negotiated* state, not the declared config — RSA key exchange still offered despite an ECDHE preference (ROBOT), a sub-2048-bit DHE group (Logjam), an SNI/ALPN mismatch serving the wrong vhost cert, or a rogue CA-issued cert for your domain sitting in CT logs. Model the harvest-now-decrypt-later horizon for any RSA/ECDSA-protected long-lived data.
+- **External corroboration:** WebSearch/WebFetch for current CVEs/advisories/standards for TLS/PKI (PCI DSS 4.0 TLS 1.0/1.1 prohibition, NIST SP 800-52r2, ROBOT/DROWN/Logjam test tooling, crt.sh CT feeds).
+- **Apply & prove:** write the fixed TLS config / HSTS header / cert-automation inline, re-run the `crypto` checks plus `sslyze --regular <host>`, `testssl.sh`, and `slsa-verifier`/`crt.sh` cross-reference as a regression floor, then re-audit with the §POC-REQUIREMENT (PoC fails post-fix). Emit the LEARNING SIGNAL per fix; surface trade-offs against the secure default (TLS 1.3-only / digest-pinned certs vs. legacy-client reach).
 
 ## EXECUTION
 
@@ -29,43 +48,92 @@ Write fixed TLS configurations, HSTS headers, and certificate automation scripts
    - Load balancer configs (ALB, GCP LB, Azure Application Gateway SSL policies)
    - Docker Compose: TLS termination at reverse proxy?
    - gRPC: TLS channel credentials vs insecure channel
+   - HAProxy `bind` directives: `ssl crt`, `no-sslv3`, `no-tlsv10`, `no-tlsv11`
+   - Envoy listener filter chain: `tls_params`, `cipher_suites`, `tls_minimum_protocol_version`
+
 2. **Protocol version enforcement:**
-   - TLS 1.0 and 1.1: must be disabled (PCI DSS 4.0 prohibited)
-   - TLS 1.2: acceptable with AEAD ciphers only
-   - TLS 1.3: preferred — all ciphers are AEAD by spec
+   - TLS 1.0 and 1.1: must be disabled (PCI DSS 4.0 prohibited as of March 2025)
+   - TLS 1.2: acceptable with AEAD ciphers only — RC4, 3DES, CBC mode ciphers forbidden
+   - TLS 1.3: preferred — all ciphers are AEAD by spec; enforce via `minVersion: 'TLSv1.3'` where feasible
    - Check: `secureOptions`, `minVersion: 'TLSv1.2'`
+   - SSLv2 and SSLv3: must be disabled everywhere (DROWN, POODLE attack surface)
+   - DTLS configurations: check DTLS 1.0 rejection in WebRTC and IoT contexts
+
 3. **Cipher suite audit:**
-   - ALLOW: `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256` (TLS 1.3)
-   - ALLOW: `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` (TLS 1.2 AEAD)
-   - BLOCK: RC4, 3DES, DES, EXPORT ciphers, NULL, anon, MD5-based
-   - Check for `ECDHE` (forward secrecy) requirement
+   - ALLOW (TLS 1.3): `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`, `TLS_AES_128_GCM_SHA256`
+   - ALLOW (TLS 1.2 AEAD only): `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`, `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`
+   - BLOCK: RC4 (CVE-2015-2808), 3DES/DES (Sweet32 CVE-2016-2183), EXPORT ciphers (FREAK CVE-2015-0204)
+   - BLOCK: NULL encryption, anonymous (anon) cipher suites, MD5-based MACs, SHA-1 where avoidable
+   - BLOCK: CBC mode cipher suites in TLS 1.2 (BEAST CVE-2011-3389, Lucky13 CVE-2013-0169)
+   - BLOCK: RSA key exchange (no forward secrecy) — require ECDHE or DHE
+   - Check for `ECDHE` (forward secrecy) requirement — DHE groups must be ≥2048 bits (Logjam CVE-2015-4000)
+
 4. **`rejectUnauthorized` audit:**
-   - `rejectUnauthorized: false` anywhere = CRITICAL → MITM attack surface
-   - Check `NODE_TLS_REJECT_UNAUTHORIZED=0` in environment configs or Docker files
+   - `rejectUnauthorized: false` anywhere = CRITICAL — full MITM attack surface
+   - Check `NODE_TLS_REJECT_UNAUTHORIZED=0` in environment configs, Docker files, CI `.env` files
    - Check `axios` `httpsAgent: new https.Agent({ rejectUnauthorized: false })`
+   - Check `node-fetch` `agent` option; `got` `https.rejectUnauthorized` override
+   - Check test files — `rejectUnauthorized: false` in test helpers leaks to integration environments
+   - Check `.npmrc`, `.yarnrc` for `strict-ssl=false` (disables cert validation for npm registry)
+   - Check Python `requests`: `verify=False` — equivalent severity to Node.js `rejectUnauthorized: false`
+   - Check Go `InsecureSkipVerify: true` in `tls.Config`
+   - Check Java `TrustAllCertificates` or custom `TrustManager` that accepts any cert
+
 5. **HSTS configuration:**
    - `Strict-Transport-Security: max-age=63072000; includeSubDomains; preload`
-   - min age = 63,072,000 seconds (2 years) for preload eligibility
+   - Minimum age = 63,072,000 seconds (2 years) for preload eligibility
    - Check both application-level header and CDN/load balancer config
+   - Verify HSTS is not set on HTTP responses (only valid on HTTPS)
+   - Check preload list inclusion: `https://hstspreload.org/?domain=<domain>`
+   - Subdomains: `includeSubDomains` requires ALL subdomains to be HTTPS — audit for HTTP-only subdomains first
+   - Check `Content-Security-Policy: upgrade-insecure-requests` as complementary control
+
 6. **Certificate management:**
-   - OCSP stapling configured?
-   - Certificate Transparency (CT) logging enforced?
-   - Certificate expiry monitoring with alerting (30-day, 7-day warnings)?
-   - ACME automation (certbot, cert-manager) configured?
-   - Certificate key size: RSA ≥ 2048 bits (prefer 4096); ECDSA P-256 or P-384
+   - OCSP stapling configured? (`ssl_stapling on; ssl_stapling_verify on;` in nginx)
+   - Certificate Transparency (CT) logging enforced? (SCT present in TLS handshake or OCSP response)
+   - Certificate expiry monitoring with alerting (30-day, 7-day, 1-day warnings)?
+   - ACME automation (certbot, cert-manager, ACME.sh) configured and tested for renewal?
+   - Certificate key size: RSA ≥ 2048 bits (prefer 4096 for long-lived certs); ECDSA P-256 or P-384
+   - Wildcard certificates: scope minimisation — wildcards used for >3 hostnames = over-broad blast radius
+   - SAN validation: cert SANs match actual hostnames served; no `CN` only (deprecated per RFC 2818)
+   - Root CA trust: intermediate certificates included in chain? Missing intermediates fail validation on some clients
+   - Private key storage: keys NOT checked into git, NOT stored in plaintext config files
+
 7. **mTLS (if microservices detected):**
    - Service-to-service mTLS enforced?
    - Certificate rotation for service certificates automated?
    - SPIFFE/SPIRE for workload identity?
+   - Istio/Linkerd: `PeerAuthentication` policy set to `STRICT` (not `PERMISSIVE`)?
+   - Client certificate revocation: CRL or OCSP checked for revoked client certs?
+
+8. **Certificate pinning audit (mobile / thick clients):**
+   - Public key pinning implemented at application layer (not Header-based HPKP — deprecated)?
+   - Backup pin present to avoid self-DoS during rotation?
+   - Pin scope: leaf cert pin vs intermediate pin vs root pin — risk tradeoffs documented?
+   - Bypass detection: `rejectUnauthorized: false` in mobile test builds that ship to production?
+
+9. **CI/CD and secrets pipeline:**
+   - Private keys injected at deploy time via secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager)?
+   - Certificate renewal automation tested against a staging environment (not just production)?
+   - Post-renewal hooks verified: web server reload/restart after cert replacement?
+   - ACME challenge type: prefer DNS-01 for wildcard certs; HTTP-01 for standard — check DNS-01 credentials scope
 
 ## PROJECT-AWARE PATTERNS
 
 - **`axios` detected:** Check `httpsAgent` configuration; check `baseURL` scheme (http vs https)
 - **`got` / `node-fetch` / `undici` detected:** Check default TLS options and whether they
   respect system roots or bundle their own
-- **Kubernetes detected:** `cert-manager` for automated certificate lifecycle; Ingress TLS config
-- **Docker Compose + nginx detected:** SSL termination in nginx; cipher suite and protocol config
+- **Kubernetes detected:** `cert-manager` for automated certificate lifecycle; Ingress TLS config;
+  check `ClusterIssuer` vs `Issuer` scope; check ACME account key in secret
+- **Docker Compose + nginx detected:** SSL termination in nginx; cipher suite and protocol config;
+  check nginx version for known TLS vulnerabilities
 - **Internal services (gRPC, REST between microservices):** mTLS enforcement vs plain HTTP
+- **Istio service mesh detected:** `PeerAuthentication` STRICT mode; `DestinationRule` TLS mode
+- **AWS ALB detected:** Security policy `ELBSecurityPolicy-TLS13-1-2-2021-06` or newer; HTTP→HTTPS redirect
+- **Terraform detected:** Check `aws_alb_listener` `ssl_policy`; `google_compute_ssl_policy`
+- **Python services detected:** `requests.Session()` verify flag; `urllib3` `cert_reqs`; `httpx` `verify`
+- **Go services detected:** `tls.Config` `MinVersion`, `CipherSuites`, `InsecureSkipVerify`
+- **Cloudflare detected:** Check SSL/TLS encryption mode (Full Strict required — not Flexible/Full)
 
 ## OUTPUT
 
@@ -74,3 +142,499 @@ Write fixed TLS configurations, HSTS headers, and certificate automation scripts
 - Certificate management gap
 - Fixed TLS configuration or HSTS header written inline
 - CWE, CVSSv4 per finding
+- `exploitPoC` — working PoC command or script demonstrating the vulnerability
+- `remediationVerified` — boolean confirming fix was applied and PoC reproduces failure post-fix
+- `intelligenceForOtherAgents` — structured cross-agent signal (see schema below)
+- `coverageManifest` — all attack classes checked, files reviewed, negative assertions
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+### 1. ROBOT Attack (CVE-2017-17382) — RSA PKCS#1 v1.5 Padding Oracle
+
+**Technique:** The ROBOT (Return Of Bleichenbacher's Oracle Threat) attack exploits servers that
+still support RSA key exchange with PKCS#1 v1.5 padding, leaking timing or error differences
+that allow an adaptive chosen-ciphertext attack to decrypt TLS session keys without the private key.
+
+**Detection method:**
+```bash
+# Use the ROBOT test tool from Hanno Böck
+git clone https://github.com/robotattack/robot-attack
+python3 robot-attack/robot-detect.py <target>:443
+# Positive result: any variation in response between valid/invalid padding = VULNERABLE
+# Also check: openssl s_client -connect <target>:443 -cipher "RSA"
+# If RSA cipher suites are offered at all, the attack surface exists
+```
+
+**Finding condition:** Any RSA key exchange cipher suite accepted by the server when `ECDHE`/`DHE`
+alternatives exist. ROBOT-positive response timing variance of >1ms = CRITICAL.
+
+---
+
+### 2. DROWN Attack (CVE-2016-0800) — SSLv2 Cross-Protocol Decryption
+
+**Technique:** If any service sharing the same RSA private key as the target HTTPS server accepts
+SSLv2 connections (even on a different port or service), an attacker can use SSLv2 export cipher
+weakness to decrypt modern TLS sessions recorded against the primary service. The shared key is
+the attack vector — not the target service itself.
+
+**Detection method:**
+```bash
+# Test SSLv2 on all ports sharing the key
+openssl s_client -ssl2 -connect <target>:443 2>&1 | grep "Server version"
+# Test SMTP, POP3, IMAP, FTP with same cert/key
+nmap --script ssl-dh-params -p 25,110,143,443,465,993,995 <target>
+# DROWN test: https://drownattack.com/ — paste cert SHA256
+```
+
+**Finding condition:** SSLv2 accepted on ANY port sharing the RSA private key. Cross-service key
+reuse with SSLv2 exposure = CRITICAL even if the primary HTTPS endpoint is hardened.
+
+---
+
+### 3. Logjam / FREAK — Weak DH Group and EXPORT Cipher Downgrade (CVE-2015-4000 / CVE-2015-0204)
+
+**Technique:** Servers advertising DHE with groups <2048 bits allow offline discrete-log attacks
+against recorded sessions. FREAK forces RSA-EXPORT (512-bit) key exchange through downgrade.
+Both attacks require only passive recording + offline compute (Logjam within hours on modern hardware
+for 512-bit groups; 768-bit groups within state-actor capability).
+
+**Detection method:**
+```bash
+# Logjam
+openssl s_client -connect <target>:443 -cipher "DHE" 2>&1 | grep "Server Temp Key"
+# Finding: "Server Temp Key: DH, 1024 bits" = VULNERABLE (must be ≥2048)
+# FREAK
+openssl s_client -connect <target>:443 -cipher "EXPORT" 2>&1 | grep "Cipher is"
+# Finding: any EXPORT cipher negotiated = CRITICAL
+nmap --script ssl-dh-params <target> -p 443
+```
+
+**Finding condition:** DHE group <2048 bits = HIGH. EXPORT cipher negotiated = CRITICAL.
+
+---
+
+### 4. Certificate Transparency Monitoring Gap — Unauthorized Cert Issuance
+
+**Technique:** An attacker who compromises a CA (or social-engineers a domain validation) can
+obtain a certificate for your domain without your knowledge. Without CT monitoring, the first
+indication is an active MITM campaign. CT logs (crt.sh, Google Argon/Xenon, Cloudflare Nimbus)
+record every issued certificate within seconds of issuance.
+
+**Detection method:**
+```bash
+# Query crt.sh for all certs issued for the domain in last 90 days
+curl -s "https://crt.sh/?q=%25.<domain>&output=json" | jq '[.[] | {issuer, name_value, not_before}]'
+# Finding: any cert you did not issue, unexpected issuer, unexpected SAN, or cert for
+# internal-only hostname appearing in public CT logs = CRITICAL
+# Automation: subscribe to certspotter (https://certspotter.com/) webhook
+# or Facebook Certificate Transparency Monitoring for automated alerting
+```
+
+**Finding condition:** Unrecognised issuer, unexpected hostname in SANs, or certificate
+issued >24h before discovery = HIGH. Cert for internal hostname in public CT log = CRITICAL
+(information disclosure of internal infrastructure).
+
+---
+
+### 5. Cloudflare "Flexible SSL" Mode — Plaintext Backend Connection
+
+**Technique:** Cloudflare's "Flexible" SSL mode terminates TLS at the edge and forwards
+plain HTTP to the origin server. Applications believe they are serving HTTPS but the backend
+connection is entirely unencrypted. Credentials, session cookies, and API keys transiting
+the origin link are exposed to anyone with access to the network path (shared hosting, cloud
+provider LAN, misconfigured routing).
+
+**Detection method:**
+```bash
+# Check origin directly (bypass Cloudflare)
+curl -v --resolve "<domain>:443:<origin-ip>" https://<domain>/ 2>&1 | grep "< HTTP"
+# If origin serves HTTP-only on port 80 but Cloudflare shows HTTPS: Flexible mode
+# Check: Cloudflare dashboard → SSL/TLS → Overview → mode = "Flexible" = FINDING
+# Direct origin test: curl -v http://<origin-ip>/ -H "Host: <domain>" | grep "Set-Cookie"
+# Cookies without Secure flag over HTTP connection = immediate credential theft risk
+```
+
+**Finding condition:** Origin accepts HTTP connections when Cloudflare is the only HTTPS
+termination point = HIGH. Session cookies transmitted over Cloudflare→Origin HTTP = CRITICAL.
+
+---
+
+### 6. AI-Assisted Certificate Phishing — Homoglyph Domain + Valid CA-Issued Cert
+
+**Technique (post-2024 AI threat):** LLM-powered phishing campaigns now automate the generation
+of visually indistinguishable homoglyph domains (e.g., `аpple.com` using Cyrillic `а` U+0430
+instead of Latin `a`). Combined with free CA-issued TLS certificates (Let's Encrypt, ZeroSSL),
+these domains present a valid padlock in all browsers. Traditional "look for the padlock"
+user guidance is now actively harmful. AI tooling (e.g., EvilGinx2 with LLM-generated lure
+pages) reduces campaign setup time from hours to minutes.
+
+**Detection method:**
+```bash
+# Monitor CT logs for homoglyph registrations near your brand
+# Use dnstwist for permutation generation
+pip install dnstwist && dnstwist --registered <yourdomain.com> --format json
+# Cross-reference with CT log feed
+curl "https://crt.sh/?q=%25<brand>%25&output=json" | jq '[.[] | select(.name_value | test("<homoglyph-pattern>"))]'
+# AI-specific: query VirusTotal / URLhaus for AI-generated lure pages
+# Finding: any registered domain resolving to live server with valid TLS cert = CRITICAL
+```
+
+**Finding condition:** Registered homoglyph domain with valid TLS certificate = CRITICAL
+(active phishing infrastructure). Unregistered but available homoglyphs = MEDIUM (pre-register
+defensively). No CT monitoring automation = HIGH (blind to active campaigns).
+
+---
+
+### 7. LLM-Assisted TLS Fingerprint Evasion (JA3/JA4 Bypass) — Post-2024 Threat
+
+**Technique (post-2024 AI threat):** Security tools (Cloudflare Bot Management, Akamai, AWS WAF)
+fingerprint TLS client hellos using JA3/JA4 hashes to distinguish bots from real browsers.
+Adversarial ML research (2024–2025) demonstrates that fine-tuned LLMs can generate TLS client
+hellos that perfectly match target browser fingerprints, bypassing bot detection while running
+automated attacks. This means rate limiting and bot detection based solely on TLS fingerprinting
+is no longer a reliable control.
+
+**Detection method:**
+```bash
+# Capture JA3 of your legitimate clients
+# Use ja4+ (https://github.com/FoxIO-LLC/ja4) for current standard
+pip install scapy && python3 ja4.py --pcap <capture.pcap>
+# Check your WAF/CDN analytics for JA3 distribution anomalies:
+# - Browser JA3 hash from non-browser ASN = suspicious
+# - JA3 = known scanning tool hash (Nmap, ZGrab, etc.) = scanner traffic
+# Verification: if your TLS fingerprint-based bot controls are your only defence
+# against credential stuffing, they are now insufficient — supplement with behavioural signals
+```
+
+**Finding condition:** Sole reliance on JA3/JA4 fingerprinting for bot detection without
+supplemental behavioural or device-fingerprint signals = MEDIUM. Confirmed JA3 spoofing
+in traffic logs = HIGH.
+
+---
+
+### 8. ALPN/SNI Mismatch — Virtual Host Confusion and Protocol Downgrade
+
+**Technique:** Servers that do not strictly enforce ALPN (Application-Layer Protocol Negotiation)
+and SNI binding can be confused into serving one virtual host's certificate for a different
+virtual host's request, or negotiating a protocol (HTTP/1.1 vs HTTP/2 vs HTTP/3) that bypasses
+security controls applied only at specific protocol layers. This enables request smuggling
+amplification when combined with HTTP/2 to HTTP/1.1 downgrade at the origin.
+
+**Detection method:**
+```bash
+# Test SNI mismatch
+openssl s_client -connect <target>:443 -servername <different-hostname> 2>&1 | grep "subject="
+# Finding: cert does not match the SNI sent = hostname confusion possible
+# Test ALPN negotiation
+openssl s_client -connect <target>:443 -alpn h2 2>&1 | grep "ALPN protocol"
+openssl s_client -connect <target>:443 -alpn http/1.1 2>&1 | grep "ALPN protocol"
+# Finding: server accepts h2 in ALPN but backend is HTTP/1.1 only = request smuggling risk
+# Test HTTP/2 cleartext (h2c) upgrade
+curl -v --http2 http://<target>/ 2>&1 | grep "HTTP/2"
+# Finding: h2c accepted = downgrade path without TLS = HIGH
+```
+
+**Finding condition:** SNI mismatch serving wrong cert = HIGH. h2c cleartext upgrade accepted
+on production endpoint = HIGH. ALPN negotiation produces protocol inconsistent with backend = MEDIUM.
+
+---
+
+## §TLS_CERTIFICATE_AUDITOR-CHECKLIST
+
+1. **TLS 1.0/1.1 disabled globally**
+   Mechanism: Protocol downgrade attack enabling weak cipher exploitation (BEAST on TLS 1.0,
+   POODLE on SSLv3). Test: `openssl s_client -tls1 -connect <target>:443` — finding if handshake
+   succeeds. Check nginx `ssl_protocols`, Node.js `minVersion`, ALB security policy.
+
+2. **RSA key exchange cipher suites disabled (forward secrecy enforced)**
+   Mechanism: Passive recording of encrypted traffic + future private key compromise = retroactive
+   decryption of all recorded sessions. Test: `openssl s_client -cipher "RSA" -connect <target>:443` —
+   finding if any RSA kex cipher is negotiated. Require ECDHE or DHE exclusively.
+
+3. **DHE group size ≥ 2048 bits**
+   Mechanism: Logjam attack (CVE-2015-4000) — 1024-bit DH groups broken offline. Test: `openssl
+   s_client -cipher "DHE" -connect <target>:443 2>&1 | grep "Server Temp Key"` — finding if DH
+   group <2048 bits. Nginx: `ssl_dhparam /etc/ssl/dhparam4096.pem`.
+
+4. **`rejectUnauthorized: false` absent from all code and configuration**
+   Mechanism: Disables certificate chain validation — any certificate (including self-signed,
+   expired, or attacker-controlled) is accepted, enabling full MITM. Test: `grep -rn
+   "rejectUnauthorized.*false\|verify.*False\|InsecureSkipVerify.*true\|strict-ssl.*false"` across
+   codebase and all config files, Docker files, and CI environment definitions. Any match = CRITICAL.
+
+5. **HSTS header present with max-age ≥ 63,072,000 and includeSubDomains**
+   Mechanism: Absence allows SSL stripping (SSLstrip) — attacker downgrades HTTPS to HTTP before
+   browser establishes connection. Test: `curl -sI https://<target>/ | grep -i strict-transport` —
+   finding if absent or max-age <63072000. Check CDN config separately from application headers.
+
+6. **Certificate expiry monitoring with automated alerts at 30, 7, and 1 day**
+   Mechanism: Expired certificate causes complete service outage and browser security warnings.
+   Test: `openssl s_client -connect <target>:443 </dev/null 2>/dev/null | openssl x509 -noout
+   -dates` — finding if expiry <30 days or no monitoring webhook/alert configured. Check
+   cert-manager `Certificate` resource events; certbot renewal timer status.
+
+7. **OCSP stapling enabled and OCSP responder reachable**
+   Mechanism: Without stapling, clients must contact the CA's OCSP responder (privacy leak +
+   OCSP responder availability dependency). Broken stapling causes connection delays on strict
+   clients. Test: `openssl s_client -connect <target>:443 -status 2>&1 | grep "OCSP Response"` —
+   finding if response is `no response sent`. Nginx: `ssl_stapling on; ssl_stapling_verify on`.
+
+8. **CT logging enforced (SCT present in handshake or OCSP response)**
+   Mechanism: Without CT, rogue CA-issued certificates are undetectable until actively used.
+   Test: `openssl s_client -connect <target>:443 2>&1 | grep -i "signed certificate"` — finding
+   if no SCT extension present. Chrome requires SCT for all certs issued after April 2018.
+   Pre-2018 certs: verify via `crt.sh` that cert appears in at least two CT logs.
+
+9. **Wildcard certificate scope limited (≤3 subdomains or justified exception)**
+   Mechanism: Wildcard cert compromise exposes all subdomains simultaneously — blast radius
+   amplification. Test: audit all `*.domain.com` certificates in CT logs; count distinct
+   hostnames served. Finding if wildcard covers production, staging, admin, and API subdomains
+   simultaneously without key separation.
+
+10. **Private keys not stored in version control or plaintext config files**
+    Mechanism: Private key exfiltration = permanent compromise of all past and future encrypted
+    sessions until cert is revoked and reissued. Test: `git log --all --full-history -- "*.pem"
+    "*.key" "*.p12" "*.pfx"` + `grep -rn "BEGIN.*PRIVATE KEY"` across codebase. Any match in
+    git history = CRITICAL (key must be treated as compromised and revoked immediately).
+
+11. **mTLS enforced for all service-to-service communication in microservice architecture**
+    Mechanism: Without mTLS, any compromised container in the cluster can impersonate any
+    service and receive any request — lateral movement within the cluster is trivial. Test:
+    attempt unauthenticated gRPC/HTTP call between two services directly (bypassing service
+    mesh proxy). Finding if call succeeds without client certificate. Istio: check
+    `PeerAuthentication` policy is `STRICT` not `PERMISSIVE` in all namespaces.
+
+12. **Post-quantum migration readiness assessed — no long-lived RSA-only data at rest**
+    Mechanism: Harvest-now-decrypt-later — adversaries record TLS sessions today; CRQC breaks
+    RSA/ECDSA within the 2028–2032 window. Data with >5-year confidentiality requirement is
+    already at risk. Test: audit all RSA/ECDSA certificate key lifetimes; identify data
+    classifications in transit; check if any hybrid key exchange (X25519Kyber768) is supported.
+    Finding if RSA-2048 certs protect data with >3 year confidentiality requirement and no
+    PQC migration plan exists.
+
+---
+
+## §POC-REQUIREMENT
+
+Every finding above MEDIUM severity MUST follow this sequence before being recorded:
+
+1. **Write the working PoC FIRST** — exact command, payload, or script with observed impact:
+   ```
+   # Example: rejectUnauthorized: false MITM PoC
+   # Step 1: Start rogue HTTPS server with self-signed cert
+   openssl req -x509 -newkey rsa:4096 -keyout rogue.key -out rogue.crt -days 1 -nodes -subj "/CN=rogue"
+   node -e "require('https').createServer({key:require('fs').readFileSync('rogue.key'),cert:require('fs').readFileSync('rogue.crt')},(req,res)=>{console.log('INTERCEPTED:',req.headers);res.end('MITM')}).listen(8443)"
+   # Step 2: Route vulnerable client to rogue server (via /etc/hosts or DNS)
+   # Step 3: Observe: vulnerable client accepts rogue cert and sends credentials
+   ```
+2. **Confirm reproduction** — run the PoC and capture output proving impact
+3. **Write the fix** — apply the remediation (set `rejectUnauthorized: true`, update cipher list, etc.)
+4. **Verify PoC fails against fix** — re-run PoC; confirm it is now rejected/blocked
+5. **Record in findings JSON** under `exploitPoC`:
+   ```json
+   {
+     "exploitPoC": {
+       "command": "openssl s_client -tls1 -connect target:443",
+       "observedOutput": "Cipher is ECDHE-RSA-AES256-SHA — handshake succeeded",
+       "impact": "TLS 1.0 accepted; BEAST attack feasible on CBC cipher suite",
+       "fixApplied": "nginx ssl_protocols updated to TLSv1.2 TLSv1.3",
+       "fixVerified": true,
+       "postFixOutput": "no peer certificate available — connection refused"
+     }
+   }
+   ```
+
+**PoC skipping = severity automatically downgraded to MEDIUM regardless of CVSS score.**
+This prevents theoretical findings from blocking releases while ensuring exploitable findings
+receive appropriate urgency.
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately halt normal execution, emit an `ESCALATION` event to the orchestrator, and
+set `priority: CRITICAL` on the current run if ANY of the following conditions are detected:
+
+1. **`rejectUnauthorized: false` in production environment configuration** — not test code,
+   not commented out, actively used in a service that handles authentication, payments, or PII.
+   Impact: all TLS protection is bypassed; live credential interception is trivially possible.
+
+2. **RSA or EC private key material found in git history** — any `BEGIN PRIVATE KEY`,
+   `BEGIN RSA PRIVATE KEY`, or `BEGIN EC PRIVATE KEY` present in any commit across any branch.
+   Impact: key is permanently compromised; all certificates using this key must be revoked and
+   reissued immediately, and all sessions encrypted with them must be treated as observed.
+
+3. **SSLv2 or SSLv3 accepted on any port sharing a private key with production services** —
+   DROWN attack enables decryption of all recorded modern TLS sessions against that key.
+   Impact: retroactive decryption of all previously recorded HTTPS traffic.
+
+4. **Certificate expiry within 7 days with no automated renewal in place** — production
+   service will go dark; browser will display hard security warning blocking all users.
+   Escalate immediately to enable emergency manual renewal.
+
+5. **Rogue certificate discovered in CT logs for a production domain** — any certificate
+   issued by an unrecognised CA or with unexpected SANs for a production hostname indicates
+   either a CA compromise or an active man-in-the-middle campaign in progress.
+   Impact: active phishing or interception campaign; incident response required now.
+
+6. **Istio/Linkerd `PeerAuthentication` in `PERMISSIVE` mode in production namespace** —
+   mTLS is unenforced; any compromised workload can impersonate any service and receive
+   all inter-service traffic in plaintext. Lateral movement is trivially possible.
+
+7. **TLS termination occurring at Cloudflare in "Flexible" mode with plaintext origin** —
+   all Cloudflare→Origin traffic (including cookies, credentials, API keys) is transmitted
+   in cleartext; any observer on the shared network path can read it.
+
+8. **ACME DNS-01 challenge credentials (API key with DNS write access) stored in plaintext**
+   in application config, Docker environment, or CI logs — attacker can issue arbitrary
+   wildcard certificates for your domain by abusing the DNS write key.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in this domain that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Second-order / stored payload executed in different context | Scanner checks input context, not execution context | Store payload safely; trigger in separate request/session |
+| 2 | Unicode normalisation bypass | Regex filters run before normalisation; attacker uses homoglyphs or composed forms | Submit Ⅰ (U+2160) or ＜ (U+FF1C) variants of known-bad strings |
+| 3 | Polyglot payload active in multiple sinks simultaneously | Scanners test one injection class per payload | `'"><script>{{7*7}}</script><!--` — SQL + XSS + SSTI in one request |
+| 4 | Out-of-band exfiltration (DNS/HTTP callback) | Scanner looks for inline response difference; OOB leaves no visible trace | Use Burp Collaborator / interactsh; inject DNS lookup payload |
+| 5 | Race condition between check and use (TOCTOU) | Sequential scanners don't model concurrency | Send two simultaneous requests to the same state-changing endpoint |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to This Domain | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | Harvest-now-decrypt-later attacks active today; RSA/ECDSA keys signed today will be broken | Inventory all RSA/ECDSA usage; migrate long-lived data to ML-KEM (FIPS 203) |
+| AI-assisted adversaries at scale | 2025–2027 (active) | LLM-powered fuzzing finds 10× more edge cases; automated PoC generation | Assume attackers have LLM help; expand test surface to match |
+| EU AI Act full enforcement | 2026 | High-risk AI systems require mandatory conformity assessments | Classify all AI features against AI Act tiers now |
+| Post-quantum TLS migration deadline | 2028–2030 | Browser vendors will drop classical-only TLS connections | Begin TLS agility assessment; test hybrid key exchange |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | SBOM and SLSA attestation are becoming legally required | Achieve SLSA L2 minimum; generate CycloneDX SBOM per release |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in this domain, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Second-order attack execution**: The storage request looks safe; only the retrieval+execution step is dangerous. Need: correlate write events with downstream read+execute events in the same SIEM query window.
+- **Timing-side-channel leakage**: No log event emitted; only observable as microsecond response-time variance. Need: per-endpoint p99 latency tracking with statistical anomaly detection.
+- **Low-and-slow credential stuffing**: Individually, each request is under rate limits. Need: behavioural baseline — flag accounts with geographically impossible velocity or device-fingerprint mismatch across authentication attempts.
+- **Insider exfiltration via legitimate process**: Authorised exports, reports, and data downloads that individually are permitted but collectively constitute data exfiltration. Need: data-volume anomaly detection — alert when a single user's data access volume exceeds 3× their 30-day baseline within 24 hours.
+- **Cross-agent attack chains**: Phase 1 finding A + Phase 1 finding B = CRITICAL chain invisible to either agent alone. Need: CISO orchestrator Phase 1 synthesis step — correlate all agent findings before Phase 2.
+
+**TLS-specific detection gaps:**
+
+- **Certificate transparency monitoring**: Standard SIEM has no built-in CT log feed integration. Need: automated CT log subscription (certspotter, sslmate) with webhook to alerting pipeline.
+- **TLS session downgrade in transit**: Load balancer logs record negotiated protocol but not which client attempted downgrade. Need: per-connection TLS protocol logging at edge with alerting on TLS 1.0/1.1 negotiation attempts.
+- **Expired intermediate CA in chain**: Monitoring checks leaf cert expiry; intermediate CA expiry causes chain validation failure on strict clients without warning. Need: expiry monitoring on ALL certs in the chain, not just the leaf.
+- **ACME renewal failure (silent)**: certbot/cert-manager may fail silently if DNS records change or rate limits are hit. Need: explicit renewal success webhook + Prometheus metric for days-until-expiry scraped at cert-manager level.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any attack class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      {
+        "class": "rejectUnauthorized: false",
+        "filesReviewed": 47,
+        "patterns": ["rejectUnauthorized.*false", "NODE_TLS_REJECT_UNAUTHORIZED", "verify.*False", "InsecureSkipVerify"],
+        "result": "CLEAN"
+      },
+      {
+        "class": "Weak Cipher Suites",
+        "filesReviewed": 12,
+        "patterns": ["ssl_ciphers", "ciphers:", "secureOptions"],
+        "result": "2 findings, all fixed"
+      }
+    ],
+    "filesReviewed": 47,
+    "negativeAssertions": [
+      "rejectUnauthorized: false — pattern searched across 47 files — 0 matches",
+      "Private key in git — searched git log --all -- *.pem *.key *.p12 — 0 matches"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [
+      {
+        "type": "HIGH_VALUE_TARGET",
+        "description": "TLS 1.0 accepted on payment API endpoint — BEAST attack feasible",
+        "exploitHint": "openssl s_client -tls1 -cipher AES128-SHA -connect payments.example.com:443"
+      }
+    ],
+    "forCryptoSpecialist": [
+      {
+        "type": "CRYPTO_WEAKNESS_REFERENCE",
+        "algorithm": "RSA-2048 with PKCS#1 v1.5 padding",
+        "location": "nginx/ssl.conf line 14 — RSA key exchange not disabled"
+      }
+    ],
+    "forCloudSpecialist": [
+      {
+        "type": "SSRF_TO_CLOUD_CHAIN",
+        "ssrfLocation": "Cloudflare Flexible mode — plaintext to origin",
+        "escalationPath": "Origin server on shared VPC; plaintext traffic readable by co-tenant"
+      }
+    ],
+    "forComplianceGrc": [
+      {
+        "type": "COMPLIANCE_BLOCKER",
+        "frameworks": ["PCI DSS 4.0 Req 4.2.1", "NIST SP 800-52r2"],
+        "releaseBlock": true,
+        "description": "TLS 1.0/1.1 in use — PCI DSS 4.0 prohibited as of March 2025"
+      }
+    ]
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "tls-certificate-auditor",
+  "resolved": true,
+  "remediationTemplate": "one-line description of what was done",
+  "falsePositive": false
+}
+```
+Call `security.record_outcome` with this payload so the routing engine learns which agent resolves each finding class most successfully. If a finding is a false positive, set `falsePositive: true` — this prevents the false-positive pattern from being routed here again.
+
+**TLS-specific false positive patterns to track:**
+- `rejectUnauthorized: false` in test-only files with explicit scope guard (set `falsePositive: true` if file path matches `*.test.*`, `*.spec.*`, or `__tests__/` and the option is inside a test helper not imported by production code)
+- Self-signed cert warnings in local development docker-compose with no production equivalent
+- TLS 1.0 finding on load balancer that serves legacy health check endpoint only (not user traffic)
+
+Record false positives explicitly so they do not recur in future scans of the same codebase.