AnyTLS implements a persistent idle-session pool with configurable parameters: idle_session_check_interval (default 30s), idle_session_timeout (default 30s), and min_idle_session (default 5). The client maintains at least 5 pre-established TLS sessions at all times to enable fast connection reuse without a new TLS handshake per request.

AnyTLS's default padding scheme operates across 8 levels (stop=8), with initial padding fixed at 30 bytes, small-data padding 100–400 bytes, and medium-to-large data padding chains of 400–500 bytes continuing through multiple 500–1000 byte segments. The 'c' (continue) marker allows multi-stage padding sequences within a single connection burst.

§2.3 defense

As of 2026, AnyTLS lacks a standardized subscription link format (unlike VLESS/Trojan/Hysteria2), requires manual JSON configuration distribution, and is supported primarily by sing-box with limited support in v2rayNG and Shadowrocket. The guide explicitly warns it is unsuitable for production environments and recommends VLESS or Hysteria2 for production deployments and Hysteria2 for high-performance needs.

§1.4, §4.8, §8.2–8.3 deployment

Compared to peer protocols, AnyTLS rates 'medium' performance (vs. VLESS 'high', Hysteria2 'very high', TUIC 'high'), uses TCP/TLS transport (vs. UDP/QUIC for Hysteria2 and TUIC), and relies on padding-based obfuscation vs. REALITY/WebSocket (VLESS) or HTTP/3 framing (Hysteria2). Client ecosystem support is currently limited primarily to sing-box, vs. broad cross-client support for VLESS, Trojan, and Hysteria2.

§1.5, Table 1.5 evaluation

AnyTLS is a TLS-based proxy protocol maintained by the sing-box team, designed in 2024 and first released in the sing-box dev-next branch. Its core mechanism wraps arbitrary proxy traffic in standard TLS and applies a configurable padding scheme (Padding Scheme) to enhance traffic concealment while maintaining compatibility with standard TLS infrastructure.

§1.1–1.3 defense

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

While stream multiplexing reduces the visibility of encapsulated TLS handshakes by merging inner connections, the paper cautions that multiplexing plus random padding alone is "inherently limited" as a long-term countermeasure. Censors can adapt by monitoring burst sizes and round-trip counts at the outer-connection level, which remain correlated with the number of inner TLS sessions regardless of padding.

2024-xue-fingerprinting §7 (Limitations and Future Work) dpitls-fingerprinttraffic-shape

Balboa runs unmodified application binaries on standard inputs, intercepting TLS via dynamic library injection (LD_PRELOAD / DYLD_INSERT_LIBRARIES) to replace plaintext with covert data while preserving all TLS record lengths and non-timing characteristics. This yields goodput of 145 kbps for audio streaming and up to 8 Mbps for web browsing, versus 2.56 kbps for DeltaShaper and 19 kbps for Freewave, both of which run real applications on non-standard inputs.

2021-rosen-balboa §1.1, Table 1 tls-fingerprinttraffic-shape

Beyond the ClientHello, circumvention tools diverge from real browsers in TLS record-layer behavior: Go's crypto/tls splits the first application-data write differently than NSS or BoringSSL, and Go does not send a TLS ChangeCipherSpec in the same byte sequence as Chrome. These post-handshake divergences are detectable even when the ClientHello has been patched with uTLS, requiring record-layer mimicry in addition to hello-field mimicry for full fingerprint resistance.

2015-frolov-the-use-of-tls §4.3 tls-fingerprintdpitraffic-shape

A DTLS fingerprinting script run on one full day of network traffic at Lawrence Berkeley National Laboratory found only 7 DTLS handshakes with 3 unique client fingerprints and 3 unique server fingerprints, suggesting there may not be enough naturally occurring WebRTC traffic to provide meaningful cover for a WebRTC-based circumvention system.

2016-fifield-fingerprintability §5 tls-fingerprinttraffic-shape

A passive observer of BridgeSPA traffic sees only a TCP connection timeout on failed authorization or a successful TLS connection on success—exactly what they would observe with an unmodified Tor bridge. The ConnectionTag is indistinguishable from the normally-random ISN and timestamp fields in Linux 2.6, so no new observable artifact is introduced. However, BridgeSPA does not address the separate problem that Tor traffic itself remains fingerprint-distinguishable from HTTPS; this is an orthogonal concern.

2011-smits-bridgespa §4, §6.2.1 dpitraffic-shapetls-fingerprint