TSG's Psiphon3 blocking (Ethiopia/E21 site) uses a dynamically-learned "Top SNI" / "Top Server IP" allowlist meant to avoid collaterally blocking shared infrastructure Psiphon3 also rides on (e.g. Google); a bug in the learning pipeline (SNI values under 3 bytes rolled back the whole DB write transaction) let the allowlist silently go stale, causing Google traffic to be misidentified and blocked as Psiphon3.
经排查，Google相关应用流量被误识别为Psiphon3导致被误封...CM学习Top SNI时，学习到小于3字节的SNI，导致该学习事务回滚，新数据未写入数据库。
Defense implications
- TSG's Psiphon3 detection keys substantially on SNI value / server-IP overlap with shared CDN infrastructure rather than payload signatures alone — riding the same fronting infrastructure as Psiphon3 inherits both its false-positive-driven allowlisting benefit and its detectability once that allowlist pipeline is hardened.
- The allowlist is learned from observed live traffic, not static config — low-volume or infrequent connections may fall outside its learning window.
Related findings
TSG's blocking of YouTube/Facebook/Twitter/Tencent at Ethiopia's IGW nodes fails for a large fraction of sessions because those sessions structurally never traverse the inspection point — quantified per-site traffic-completeness rates ranged from 0% to 40% (vs. ~100% completeness at the upstream PE node), with roughly half of sampled YouTube/Facebook sessions missing entirely from IGW-side logs. Root cause was traffic-splitting/mirroring architecture, not a detection failure of the DPI engine itself.
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.
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).
TSG engineers explicitly acknowledged to an Ethiopia customer that the system's application-identification statistics over-count Psiphon3 and Freegate due to misidentification, inflating their apparent traffic share (e.g. Psiphon3 appearing in the application Top-2 despite the customer reporting no active blocking of it), and that Netflix's ranking also varies drastically by sort metric (bytes vs. sessions vs. unique client IP).
Multi-engineer forensic investigation (pcap, JA3 hashing, TSG session-log correlation) at an Ethiopia site into tv.cctv.com being intermittently unreachable concluded the blocking was NOT done by TSG itself but by a separate, more-client-proximate network censorship system. That system dropped ClientHello-stage TLS1.2 sessions matching cctv.com's SNI, had degraded filtering ability once the client renegotiated to TLS1.3, and at one point misclassified cctv.com traffic as TikTok.