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).
先策略生效，再打开应用，windows、苹果和安卓客户端策略均有效果且有策略命中日志生成；先打开应用，后生效策略，windows、苹果和安卓客户端策略均无效果且无策略命中日志和会话日志产生。
Defense implications
- Policy evaluation appears to be per-new-connection at handshake time, not applied retroactively to already-established sessions. A client that establishes and holds a persistent tunnel before a new signature/IP-list update is deployed evades that specific update entirely.
- Same ticket shows SNI-based signatures broke once the app's Google Play build changed (v1.0.0) and required re-extraction, and that once SNI failed, the team fell back to server-IP blocking — confirms SNI rotation/spoofing forces a slower, IP-based fallback.
Related findings
Ethiopia (E21) customer specifically tested Melon VPN and Ultrasurf against TSG; Ultrasurf's frequently-rotating IPs required an updated signature (successfully blocked after update), while Melon VPN's connection succeeded but was non-functional for other reasons (not attributed to TSG blocking).
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.
Ethiopia customer (E21/E-site) explicitly requested TSG blocking be extended beyond the baseline (Psiphon 3) to a named list of commercial VPNs: Freegate, CyberGhost, Torguard, NordVPN, IPVanish, VPN Unlimited, ExpressVPN, Surfshark, Windscribe, Hotspot Shield, Ivacy, Atlas VPN, PureVPN, ProtonVPN, Norton Secure VPN. Engineering confirmed delivery of NordVPN and Hotspot Shield signatures with successful field tests.
Root-caused an Ethiopia SNI-block-failure incident to the detection mechanism itself: APP_SKETCH's FQDN-scanning module -- which exists specifically to identify Psiphon3 and Freegate via top-N SNI matching -- was CPU-expensive enough to saturate cores, triggering sapp's fail-open DDoS bypass and letting some target connections through uninspected. A signature-structure fix roughly doubled throughput (33K/s to 73K/s new connections) and disabling the fail-open bypass restored reliable blocking.
Project "E21" tested SNI-FQDN-wildcard block policies against international news/media/academic domains -- opride.com (Oromo news), ethiotube.net, Reuters, NYT, Bloomberg, GitHub, ResearchGate, NIH.gov -- from an Ethio-Telecom-range office IP. Most blocks silently failed (shared root cause with OMPUB-466); britannica.com needed a separate deny-quic policy since QUIC bypassed SNI blocking.
TSG maintains a traffic-volume-ranked "Top SNI" / "Top Server IP" allowlist (Galaxy component, learned from live traffic, capped at top ~2000 SNIs / ~40000 server IPs per Nacos config) that is checked before a VPN/circumvention-tool deny policy (including a Psiphon3-specific policy) is enforced. Confirmed empirically: Psiphon3 client traffic whose destination SNI was in the Top SNI list passed through undenied, while traffic to the same client IPs with an SNI not yet in the list was blocked. A 2022-06 incident over-blocked TikTok/BBC/CNN/NYTimes because their SNIs were not yet in the learned allowlist at the time.