A security policy literally named "Lantern_vpn_test" was configured and actively enforced at the M22 (Myanmar) TSG deployment as of June 27 2024 — Lantern had a live, named blocking policy in production, not just a backlog research item.
M22现场下发一条策略："Lantern_vpn_ test"，策略详情如图...策略于2024-06-27 09:52:24已经限定Source IP Address
Defense implications
- Confirms an active, named Lantern-blocking policy in production, not a theoretical target — treat as materially live.
- The bug under investigation (policy match scope silently drifting between IP+destinationIP and IP+AppID conditions) shows TSG's rule-compile engine (maat) can misapply broader-than-intended match criteria — not defensively reliable, but useful context on how brittle the underlying policy engine can be.
Related findings
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.
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).
Geedge ran an ongoing, systematically-numbered program extracting detection fingerprints for individual VPN and non-VPN apps for the Myanmar (M22) deployment, tracked with weekly-cadence per-app tickets; methodology combined packet capture, DNS/domain analysis, and fixed-port protocol identification, validated in a live test environment before shipping, with results tracked as "CT" (successfully blocked) or not.
Myanmar deployment (M22) systematically reverse-engineered and blocked Orbot (Tor's official Android client) and ProtonMail, alongside numerous consumer VPN apps, via the AppSketch feature-extraction pipeline. Orbot: 287 server IPs extracted across multi-hop nodes, one connection mode fully blocked. ProtonMail: mail server IPs/FQDNs extracted, blocking verified as full service denial (cannot send, receive, download attachments, or create a new account) on Android and iOS.
M22 runs a large-scale automated pipeline against numerous commercial VPN apps: APK decompilation + HTTPS-proxy interception to extract servers/FQDNs, automated dial-testing at volume (one app: 17,554 dial-tests, 4,073 servers discovered, 94% 24-hour block rate), and OpenCV-based automated ad-dismissal to keep test automation running unattended.
Geedge's VPN-app signature-extraction methodology (M22/Myanmar project, run weekly per-app) is primarily IP-address-list-based rather than protocol-fingerprint-based: automated scripts enumerate each VPN app's server IPs (extraction runs cited pulling 7-200+ IPs per test cycle for apps like BigMama VPN, Giti VPN, JumpJumpVPN), which are then pushed as blocking signatures and validated against a live test environment plus a separate false-positive ('误封') test environment before deployment.