Security & Technical Transparency — SuperDMZ

Traffic flow:

Each public node is a dedicated machine in a region (currently São Paulo, Virginia, Frankfurt and Tokyo). All client-node communication runs over TLS 1.2/1.3.

• Request content (URL, headers, body) lives in RAM on the node for the time required to forward it to your client (typically milliseconds).
• That content is never written to disk, never indexed, never logged in cleartext. Nginx access logs only record operational metadata: timestamp, HTTP method, path, status, request/response bytes, response time, source IP.
• Cookies, auth headers (Authorization, Cookie) and POST bodies never appear in logs.
• SuperDMZ internal tokens (used by clients to authenticate at the node) are automatically redacted before any logging.

Honest implication: technically, a malicious operator with root on the node could intercept content in RAM while it is being forwarded. This applies to any reverse-tunnel service with TLS terminated at the edge (ngrok, Cloudflare Tunnel, localtunnel). For scenarios where this is unacceptable (PCI-DSS, healthcare, sensitive corporate secrets), we recommend the TCP mode described below.

• SSH, RDP, MySQL and any TCP protocol that carries its own encryption (including TLS offered by your own service) reach the destination end-to-end encrypted.
• SuperDMZ only sees: source/destination port, byte count, connection start/end timestamps.
• This is the recommended mode for any regulated workload (healthcare, finance, industrial secrets) and for IT administrators who need access to internal machines without handing keys to any party along the chain.

• Request or response body.
• Headers Authorization, Cookie, Set-Cookie, X-Auth-Token and known variants.
• Sensitive query strings (API keys passed via URL — discouraged, but redacted before logging if present).
• SuperDMZ internal tokens exchanged between client and node (redacted via log filter before reaching any file).
• Content of TCP tunnels of any kind.

Nginx logs are retained for 14 days. Audit logs in the panel (login, tunnel CRUD) are retained for 90 days. Full details in the Privacy Policy.

• SSH with password auth only for a non-privileged user. Root login via SSH disabled on every node.
• Firewall (UFW) with minimal whitelist: 22/tcp (SSH), 80/tcp (HTTP→HTTPS redirect + Let's Encrypt), 443/tcp (public HTTPS + client WebSocket).
• fail2ban with progressive bans for brute-force attempts on SSH and on the admin panel.
• Automatic security updates (unattended-upgrades).
• DNS resolver pinned to 1.1.1.1 / 1.0.0.1 (Cloudflare) + 9.9.9.9 (Quad9). /etc/resolv.conf with chattr +i flag to resist cloud-init overwrites.
• Admin panel on a non-obvious path and protected by rate-limit, 2FA, CSRF token on every POST and automatic IP-ban on repeated failed attempts.
• Sensitive secrets (Stripe key, SMTP password, GoDaddy token) encrypted at rest in the database, with key stored outside version control.

Failover is currently manual. If a node goes offline, the procedure is to repoint the node's A record at Cloudflare to another healthy IP (DNS change with 60s TTL) — clients reconnect automatically once DNS updates. Typical detection + action time: 5–30 minutes depending on time of day.

We do not sell a contractual SLA. The Business plan includes priority support (initial response within 4 business hours) — not a guaranteed downtime credit. Promising an SLA requires measured history, and we are still collecting that data before we publish a number we can defend. Same posture we take on external audits: radical transparency over selling promises we can't back.

Real-time public status: superdmz.com/status — shows each node's state (online/offline) and recent incidents, with auto-refresh every minute.

On the availability roadmap: automatic failover via health-checks + DNS rewrites through Cloudflare's API; month-by-month uptime history on the status page; SLA publication as soon as we have 6 months of consistent data.

• Passwords stored as bcrypt hashes with industry-recommended cost factor. Never in cleartext, not even in error logs.
• 2FA currently available: 6-digit code by email (opt-in, per user).
• Near-term roadmap: TOTP-based 2FA (Google Authenticator, Authy, Aegis) and Passkeys/WebAuthn — see "Security roadmap" below.
• Changing the primary email requires a code on the new address + an alert on the old address with a "block account now" link (7-day window).
• Account deletion has a 48h recovery window via email link before the final purge.

• TOTP 2FA (RFC 6238): QR-code setup, backup codes, email as recovery fallback.
• Passkeys / WebAuthn: passwordless, phishing-resistant authentication aligned with FIDO2.
• HTTPS passthrough (SNI routing): public HTTPS without TLS termination at the SuperDMZ edge (BYO certificate).
• Open-source client: Go client code published for auditing by anyone running the binary inside their own network.
• Public security changelog: internal CVEs and fixes documented at /changelog.
• Full asset self-hosting: remove remaining CDN dependencies (fonts, icons, Tailwind) by serving everything from our own domain — aligned with our zero third-party tracking stance.

No public SLA yet. This section will be updated as each item ships.

• Preferred channel: [email protected]
• Equivalent technical contact: [email protected]
• Operational contact: [email protected]
• RFC 9116 file: /.well-known/security.txt

What we ask: do not exploit beyond what is required to confirm the vulnerability, do not access other users' data, and give us a reasonable window to fix before public disclosure. In return: initial reply within 5 business days, public credit (if desired) and free months of paid plan as a thank-you — proportional to severity.