ShadowTLS is structurally limited to TLS 1.2 because in TLS 1.3 the Finished message is sent as encrypted Application Data (record type 0x17), preventing the relay from detecting handshake completion without decrypting the session. This forces ShadowTLS to advertise TLS 1.2, which is an increasingly anomalous fingerprint as TLS 1.3 adoption grows.

Combining all three active probing attacks in an Internet-wide scan of 30 million HTTPS servers identified approximately 15,000 hosts (0.05%) behaving like ShadowTLS relays; of these only 6,000 presented TLS certificates for Alexa Top 1000 domains. The scan successfully discovered all four researcher-operated ShadowTLS relays planted as ground truth.

§3.2, Table 2 evaluation

The root vulnerability in ShadowTLS is that the relay cannot authenticate post-handshake data from the real mask site, causing it to silently absorb censor probes. The fix — deployed in ShadowTLS v0.2.3 — has the client re-derive the Application Data encryption key from the server random and the client-relay shared secret; unrecognized records (lacking the shared secret) are transparently forwarded to the mask site, so all censor-visible responses come from the real mask server.

§4 defense

ShadowTLS relays are detectable via three active probing techniques exploiting behavioral discrepancies from the mask sites they mimic: (1) responding to plaintext HTTP on port 443 with FIN-ACK rather than an error (only 17% of TLS servers share this behavior), (2) silently ignoring non-TLS record data post-handshake rather than sending a fatal alert (only 0.14% of 30M hosts behaved this way), and (3) silently ignoring corrupted TLS Application Data records rather than sending a bad_record_mac alert (only 0.12% of hosts silent).

§3.2 detection

ShadowTLS's TLS ClientHello fingerprint (JA3 hash ebaa863800590426) was not observed in the TLSFingerprint.io dataset collected from a university network tap, making the client fingerprint unique to the tool and trivially blockable by censors maintaining a TLS fingerprint blocklist.

§3.2 detection

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