The protocol filter's HTTPS fingerprint requires only that the first 5 bytes match a TLS header (type 0x16, version 0x03 0x01–0x03, correct length field); all subsequent bytes of the Client Hello are unchecked. Any TLS-based circumvention tool naturally satisfies this fingerprint and will bypass the filter by default. Furthermore, any one of the three permitted fingerprints (DNS, HTTP, HTTPS) can be used on any of the three monitored ports to whitelist an entire flow.

Using Geneva's genetic algorithm trained against Iran's live protocol filter, four evasion strategies achieving 100% success were discovered in under two hours: (1) injecting a fingerprint-matching PSH/ACK with a corrupt checksum before the real data; (2) sending two FIN packets before the SYN; (3) sending nine non-data-carrying packets (any flags, any seq/ack) during the handshake to exhaust the filter's per-flow packet limit; (4) a server-side variant that sends nine corrupted SYN+ACKs, inducing nine client RSTs before the real ACK, enabling fully unmodified clients to benefit.

§5.2–§5.3 defense

Testing the Alexa top-20,000 websites from within Iran, 3,595 IP addresses (17.9%) triggered the protocol filter at least 8 out of 10 times, and 3,499 (17.4%) were affected all 10 times. IP address provider is not correlated with filtering; instead, specific IP prefixes are targeted—for Cloudflare, only two prefixes (104.18.0.0/16 and 104.31.82.0/24) were fully affected while all others were unaffected.

§4.2 evaluation

Iran's protocol filter monitors only the first two data-carrying packets of a TCP connection on ports 53, 80, and 443, permitting only DNS, HTTP, and HTTPS. Once tripped, it drops all subsequent client-side packets for 60 seconds, with the timer resetting on each TCP retransmit. The filter is unidirectional (client-inside-Iran only), cannot reassemble TCP segments, and does not verify checksums.

§4.1 detection

Existing segmentation strategies effective against Iran's standard HTTP DPI can be counterproductive when the protocol filter is also active: if the first segment is fewer than 8 bytes, it fails the HTTP fingerprint check and trips the filter. However, segmenting such that the first segment is a valid HTTP fingerprint (≥8 bytes, well-formed verb + space) while splitting the Host: header into the second segment defeats both the protocol filter and the standard DPI censor simultaneously.

§5.1 defense

The DTLS ClientHello extensions field is the most prominent feature for fingerprinting Snowflake's Pion WebRTC stack. A passive DPI tool (dfind) validated against the MacMillan et al. dataset of 6,500 DTLS handshakes reliably identifies Pion-based implementations via unique extension byte patterns. Chrome randomized its extension list order starting with version 129.0.6668.58 (September 2024), yielding 6! = 720 unique permutations and hardening it against deterministic matching. Firefox adopted DTLS 1.3 by default from version 127 (May 2024), which changes the extension structure entirely and renders DTLS 1.2 mimicry obsolete for Firefox traffic.

2025-midtlien-fingerprint-resistant §3, §4.1 tls-fingerprintdpi

Beyond business-filing cross-references, the paper introduces a method of linking VPN provider families by showing they share VPN server cryptographic credentials (Shadowsocks passwords, server TLS fingerprints) across distinct app identities. This extends prior ownership-attribution methods that relied solely on corporate registry data and code similarity, adding shared live infrastructure as a linkage signal that is harder for operators to obscure.

2025-mixon-baca-hidden §3 (Methodology), §4 tls-fingerprintdpi

MinecruftPT encodes circumvention traffic steganographically inside the Minecraft Java Edition network protocol, making a censored connection appear to a network observer as an ordinary online Minecraft game session. The cover channel is a high-volume, varied-packet-size TCP protocol with a large and active user population, making statistical fingerprinting harder than for lower-volume cover protocols.

2025-tusing-minecraft-tunnels §1, §3 dpitraffic-shapetls-fingerprint

Testing from a VPS in Iran showed that standard DTLS handshakes are blocked at that vantage point, but Oscur0 avoids this blocking by transmitting only Application Data packets (with Connection ID extension per RFC 9146) after the initial one-shot setup packet, never completing a visible DTLS handshake. A proof-of-concept was implemented in approximately 600 lines of Go using the pion/dtls library.

2024-chen-extended §3 Design / Implementation dpitls-fingerprint

TLS-Attacker's Workflow Traces and Modifiable Variables mechanisms allow testers to specify arbitrary protocol flows and apply field-level modifications — including adding, removing, or overwriting individual TLS message fields — without breaking the internal TLS state machine. This makes it the standard instrument for probing how DPI systems and active-probing detectors respond to non-standard or mutated TLS handshakes.

2024-niere-tls-attacker §1 Introduction tls-fingerprintactive-probingdpi

Obfuscated proxy traffic (including Shadowsocks, VMess, VLESS, Trojan, obfs4, and REALITY) can be reliably fingerprinted by detecting encapsulated TLS handshakes — the inner TLS ClientHello that appears inside an outer encrypted tunnel. This fingerprint is protocol-agnostic: any proxy that wraps TLS-bearing application traffic will produce it. The authors deployed a similarity-based classifier within a mid-size ISP serving over one million users and demonstrated detection with minimal collateral damage.

2024-xue-fingerprinting Abstract, §5, §7 dpitls-fingerprintml-classifier