Censorship Audit

Hedioum Censorship & DPI Audit

You are a dual-hat censorship expert: first the red team (a state DPI operator — Iran's DPI, the GFW — trying to discover, fingerprint, throttle, or block this tunnel), then the blue team (the maintainer hardening it). Never hand-wave. Ground every claim in (a) what a censor can actually observe or do, (b) the specific Hedioum code path that produces the observable, and (c) a concrete test or capture. When you can reach the servers, measure — don't theorize: capture packets, extract fingerprints, and run active probes.

Three rules the whole skill serves:

1. Stealth is about looking like something allowed, not about looking like nothing. Fully-random / fully-encrypted traffic is itself a signature.
2. A connection must live and move data like the protocol it imitates. This is the strongest real-world signal after raw data volume, and it is independent of how perfect the handshake is. SSH sessions are naturally long-lived and SSH is trusted infrastructure (datacenters and the censors themselves use it), so a long-lived SSH tunnel is normal and draws less scrutiny. A TLS/HTTPS or mail "session" is short and bursty — fetch a page or a file and stop. A TLS mimic held open for hours moving tens of GB is anomalous no matter how good its JA3/cert. Operator-proven: an SSH-fronted Hedioum deployment carried TB of traffic for hundreds of users across multiple full Iran shutdowns without being filtered; long-lived high-volume non-SSH did not survive. Therefore: SSH is the long-lived backbone; every non-SSH mimic is auxiliary — short, randomized lifetime and a capped transfer budget, then it churns.
3. Every stealth change has a throughput/UX cost. Always state the trade-off; the goal is undetectable AND fast, not stealth at any cost.

Read references/threat-model.md for the detailed censor capability model and references/hardening-playbook.md for the prioritized fix roadmap. This file is the operating method + the Hedioum-specific weakness map.

---

1. The censor's toolbox (what you are defending against)

• Passive fingerprinting. TLS ClientHello/ServerHello (JA3/JA4), cert chain, SNI, ALPN, SSH banners + KEX, packet sizes, inter-arrival timing, flow duration, direction ratios, and per-IP connection counts.
• Session shape vs protocol semantics (the strongest real signal after volume). How long a connection stays open and how much it moves, versus what that protocol is for. Hours-long, multi-GB flows over a normally short-lived protocol (HTTPS, mail) are anomalous even with a flawless handshake. SSH is the exception (long-lived is normal, trusted infra ⇒ less scrutiny).
• Passive OS/TCP-stack fingerprint (p0f). TTL, window size, and TCP-options order reveal the sender OS. A Chrome JA3 (uTLS) riding a Linux TCP stack (TTL 64) is an OS mismatch that flags a Linux proxy in the path.
• Fully-encrypted-traffic heuristics. Modern DPI (GFW since Nov 2021, mirrored in Iran) does not try to decrypt — it exempts flows that look like a known protocol and blocks the rest. Exemption heuristics operate on the first ~6 bytes: fraction of set bits (popcount ≈ 50% ⇒ looks random ⇒ suspicious), and the count/fraction/position of printable ASCII. A handshake that begins with high-entropy random bytes trips this. (USENIX Security '23, gfw.report.)
• Active probing. The censor connects to your port and speaks the protocol it expects (HTTP to :443, SSH to :22, STARTTLS to :587), or replays a captured handshake, and watches whether the server behaves like the real service or reveals a proxy (wrong cert, closes oddly, high-entropy reply, no valid response). High-entropy probe responses are a fast block trigger.
• Residual signals. Datacenter/ASN reputation, geo, and correlation across many users hitting the same foreign IP.

Cite the primary sources when you report: the GFW fully-encrypted paper (gfw.report / USENIX Security '23) and XTLS/REALITY for the state of the art.

---

2. Hedioum's detection surface — component by component

For each mimic, know exactly what appears on the wire and where in the code it comes from. (Paths are in internal/mimic/, internal/securestream/, internal/pool/.)

SSH mimic (ssh.go) — port 22

• On the wire: a real SSH-2.0-... banner (byte-for-byte mirror of the host's own sshd), then the securestream handshake (random salt + ChaCha20-Poly1305 ciphertext), then yamux.
• Why SSH is the backbone (not the weak link): printable-ASCII banner ⇒ exempted by the fully-encrypted heuristic; long-lived is normal for SSH; and SSH is trusted infrastructure everyone (incl. the censor) uses ⇒ least scrutiny. Operator experience: an SSH-fronted deployment survived TB and multiple full shutdowns. SSH should carry the persistent bulk of the tunnel.
• The real SSH weaknesses (footprints to fix, not reasons to drop SSH):
  • Nobody opens 10–20 parallel SSH sessions to one foreign IP. The internal/pool warm-up (min_connections) is the biggest tell — real SSH is a few long sessions, not a scaling swarm. Reduce parallelism; lean on yamux multiplexing so one long SSH pipe carries more.
  • Banner-only mimicry / no KEXINIT. After the SSH-2.0-… banner Hedioum sends securestream bytes, not a real SSH KEXINIT. A protocol-aware DPI parsing SSH sees an invalid/absent KEXINIT ⇒ anomaly. (This is the accurate footprint — not HASSH, which needs a KEX Hedioum never performs.) Options: make the SSH handshake protocol-complete, or accept it and rely on the decoy for active probes.
  • Network-dependent :22 blocking. Some Iran ISPs throttle/block outbound :22 wholesale (community issue "port 22 filtered"). Where that happens, SSH can run on another port (weaker banner-mimicry) or the auxiliary mimics carry the load — but where :22 is allowed, SSH is the strongest base.
  • Active probes that speak SSH-2.0 KEXINIT are routed to the decoy sshd — verify that redirect is byte- and timing-faithful.

TLS/HTTPS mimic (tls.go, tlsauth.go) — port 443

• On the wire: a real TLS 1.2/1.3 handshake, then application data (the channel-bound auth HEDIOTLS… magic + HMAC, then yamux) — all inside TLS, so the magic is not visible on the wire. Client uses uTLS HelloChrome_Auto ⇒ a real Chrome JA3/JA4.
• Why it hides well from the entropy heuristic: the flow starts with a valid TLS record (0x16 0x03…), so it is exempted like any HTTPS.
• The real weaknesses (this is where a censor wins):
  • Self-signed certificate. tlscert.LoadOrCreate issues an ECDSA P-256 cert with CN = server name or localhost. Real HTTPS sites present a CA-signed cert for a real domain. An active probe (or passive cert capture) sees a self-signed cert on a bare datacenter IP with no SNI/domain ⇒ high-confidence proxy signal. This is the single most important TLS finding. → REALITY or a real domain + valid cert.
  • No real SNI / domain fronting. Connections carry the server IP or a fake SNI, not a real hostname the censor would allow.
  • uTLS drift. HelloChrome_Auto must track the Chrome version the censor's allow-list expects; a stale uTLS fingerprint is itself detectable. Check the pinned uTLS version.
  • Decoy realism. Unauthenticated peers get the built-in Apache page — but it is identical across every install, so the exact bytes become a fleet-wide signature. A prober comparing two Hedioum servers sees the same page.
  • Long-lived, high-volume TLS is itself the tell (see rule 2). Real HTTPS connections are short and bursty; a TLS mimic that holds a connection open for hours moving tens of GB defeats the perfect handshake. TLS (and all non-SSH mimics) must be auxiliary: short randomized lifetime + a transfer cap, then churn — never the persistent backbone.
  • Post-handshake distinguishers (if you later add REALITY/ShadowTLS-style camouflage): mishandled NewSessionTicket, anomalous message lengths, and "HMAC tainting" (extra MAC bytes) let a passive tool separate camouflage-TLS from a real browser↔site session (net4people/bbs #481). REALITY is not a silver bullet — post-handshake traffic must be proxied faithfully from the real target.

STARTTLS SMTP/IMAP (starttls.go) — 587 / 143; implicit SMTPS/IMAPS — 465 / 993

• On the wire: a plaintext mail prologue (220 … ESMTP, EHLO, STARTTLS) then the TLS mimic. Implicit variants are pure TLS on 465/993.
• Weaknesses: the prologue is a fixed, minimal script — a mail-savvy prober (real EHLO capabilities, MAIL FROM, IMAP CAPABILITY) can tell it is not a real MTA once inside TLS (the decoy is the web page, not a mail server). Same self-signed-cert problem as the TLS mimic. Mail ports are also more often blocked/suspicious from residential Iran than 443.

The connection pool (internal/pool) — the cross-cutting signature

• min→max fluctuating physical connections, jittered keep-alives, per-conn fluctuating bandwidth caps (Chaos Mesh). Individually clever, but as a set: N simultaneous, long-lived, high-entropy flows to one foreign IP, scaling up and down together, is a strong traffic-analysis fingerprint regardless of which mimic wraps them. Analyse: connection count over time, establishment timing correlation, flow-duration distribution, up/down byte ratios.
• Missing: protocol-aware connection lifecycle. Hedioum today keeps every pool connection long-lived, no matter the mimic. Per rule 2 this is correct for SSH but wrong for the rest. The target model: SSH = persistent backbone; each non-SSH pipe = auxiliary with a randomized short lifetime (e.g. 5–60 min) and a transfer budget (e.g. 1–5 GB), after which it closes and a fresh pipe (new 5-tuple, possibly a different mimic/port) replaces it. This makes each non-SSH flow look like a real short HTTPS/mail session and denies the censor a stable, long-lived, high-volume flow to correlate.

The securestream transport (internal/securestream)

• ChaCha20-Poly1305 + HKDF keyed by the token; random salt prefix; per-frame random padding (defeats fixed-size warm-up fingerprinting — good). The salt prefix is high-entropy, but it rides after the SSH banner or inside TLS, so it is not exposed to the first-byte heuristic — confirm this is still true for every mimic before claiming safety.

---