A K18 customer specifically requested TSG support for TCP-segmented TLS ClientHello messages, confirming this was previously an inspection gap; Geedge shipped a fix ("Hotfix-Inspection-TLS-PQC-Extension") in 2024, and the same hotfix name indicates TSG's TLS inspection also tracks post-quantum-crypto ClientHello extensions.
K18业主希望在TSG 7400（ADC）上支持ClientHello分段...已提供Hotfix-Inspection-TLS-PQC-Extension更新包支持TLS Client Hello TCP分段
Defense implications
- TCP-segmented ClientHello was a working evasion technique against TSG until this 2024 patch — no longer reliable on patched deployments, but worth checking whether all export sites have received this update.
- TSG's inspection already accounts for TLS PQC extensions, so relying on newer/uncommon TLS extension fields alone is not a safe future evasion assumption.
Related findings
Raw TSG session_record export logs dated Nov 2024, tagged device_group 'YGN-MYTEL' (Yangon, Mytel), directly corroborate the leak's M22=Myanmar/Mytel/Yangon site-codename mapping with live production data: individual SSL sessions are classified by app as 'Hotspot Shield VPN' (destination get.adobe.com, likely a fronting/CDN endpoint) and allowed under a named whitelist rule 'whitelist_102024', geolocated client-side as Myanmar.Yangon.Yangon.
MESA_Platform's "quic" module (built and packaged as stellar-on-sapp/sapp RPMs) implements SNI/User-Agent extraction from both cleartext GQUIC (versions 23-59) and encrypted IETF QUIC RFC9000 ClientHello payloads, and supports a QUIC SNI whitelist -- i.e. the DPI pipeline decrypts/parses encrypted QUIC handshakes to recover the destination domain rather than being blocked by QUIC's encryption.
TSG's QUIC-parsing layer decrypts QUIC ClientHello payloads and parses a user-agent-like parameter from the decrypted content, deployed at the Ethiopia (E21) DIR-IGW site. A missing bounds check on this field caused a watchdog-timeout crash, confirmed via a MESA_Platform/quic GitLab commit (git.mesalab.cn/MESA_Platform/quic).
A 3-month E21 (Ethiopia) investigation into unreliable YouTube blocking found two independent, structural detection gaps: (1) at IGW (international gateway) sites, load-balanced multi-path routing causes TSG to see only single-direction (C2S-only or S2C-only) traffic for a meaningful fraction of sessions (~5-10% baseline, worse under load), breaking stateful app-ID/deny; (2) under peak load, NPB boards' CPU-triggered self-protection "bypass" (fail-open passthrough) hit ~50% of new sessions at the busiest site (Bole-IGW, ~86k new sessions/sec at 7.8Gbps/NPB), and TSG explicitly deprioritizes bypass protection for non-HTTP/SSL traffic to preserve web blocking under load.
A debugging ticket for sites "Old Airport-PE" and "Bole-IGW" (naming consistent with Addis Ababa, Ethiopia) confirms the customer verified Psiphon3, YouTube, Facebook, and Telegram blocking as working well during independent testing, and reveals the operational session-correlation method used when packet captures and system logs must be cross-referenced across NAT: JA3_HASH + server IP + client public IP + SSL SNI.
Geedge's M22 (Myanmar) team ran an active fingerprinting program specifically against "lanternVPN" in Aug 2024. They found the Android client's TLSv1 connections have fixed-position header fields (protocol version, payload length) usable as a static byte-pattern block signature, and that fake-SNI TLS 1.2/1.3 connections could only be blocked via destination-IP lists. They then built an automated pipeline (JA4 flow classification + domain/IP correlation + emulator-driven "new device" node discovery) that harvested 400-800+ new server IPs per week over the following month.