geedge.lantern.io
detection confidence: high public

Geedge's own engineer explicitly documented that FQDN+JA3-based blocking of Panda VPN at the M22 (Myanmar) site was incomplete ("阻断并不完全还是会有穿透的数据流") and that the surviving traffic showed no identifiable signature, forcing a fallback to static server-IP blocklisting (216 IPs extracted across free/VIP nodes, tested on Android/iOS/Windows).

通过FQDN与ja3进行阻断,阻断并不完全还是会有穿透的数据流。穿透数据流根据观察没有明显的特征,只能通过server ip进行阻断

Defense implications

censorsmm
productstsg
capabilitydpi-signature

extracted_by: claude-sonnet-5 · added 2026-08-26 · id: 2026-oss286-pandavpn-ja3-fqdn-gap

Related findings

detection

Geedge runs an ongoing, systematically-numbered VPN/app fingerprinting program for the M22 (Myanmar) deployment — a tracked "M22-VPN List" with 188+ sequentially numbered entries, and a separate non-VPN app catalog past entry 550 — with weekly-cadence re-testing (e.g. Quark VPN patches issued repeatedly through late 2024 as the target app's own infrastructure changed).

defense

Multi-week TSG engineering investigation of iTOP VPN (requested by an Ethiopia deployment, cross-tested in a Myanmar environment) found blocking only takes effect for VPN sessions established AFTER a detection policy is pushed; a VPN already connected before the policy loads is never blocked or logged, regardless of signature type (SNI or server-IP).

detection

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.

export/sales

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.

detection

The tango/kni (Kernel Network Interface) repo shows TSG's SNI/TLS-ClientHello-based interception logic (kni_entry.cpp) receiving dedicated 2024 fixes for handling TLS ClientHello fragmented across multiple packets ("ssl chello frag") and a "chello first packet hit intercept policy" bug, on top of a long-standing (2020) "dynamic bypass" feature that replaced raw-ClientHello matching with JA3 TLS fingerprints, plus counters for SSL certificate-pinning detection.

deployment

Under the internal "M22" project (deployment site "YGN-MYTEL" confirms this is Myanmar, at the Mytel carrier), Geedge runs a continuous, individually-tracked signature-extraction pipeline against named commercial VPN apps (Super Unlimited VPN, NotVPN, Avira Phantom, Bitdefender VPN, Thunder VPN, Panda VPN, Mouse VPN, HaloVPN, GoFly VPN, Kiwi/Kuto/Greennet/Gulf Super/Hatunnel+ VPN, and a customer-provided list of 141 more): active probing of app refresh/connect behavior (including automated UI-driving scripts) extracts server IP/FQDN lists, separately for free vs. paid tiers and Android vs. iOS, which are then loaded as blocklist objects and validated against a false-positive ("CT"/穿透) test pass in a separate demo environment before deployment.