TSG's 'APP' classification feature has named, purpose-built signatures for specific circumvention tools — the ticket explicitly configures active-client-IP tracking for the APP categories Freegate, Psiphon3, and Tor.
针对内存使用测试及现场数据查询,对APP推荐活跃Client IP增加指定统计 *Freegate,Psiphon3,Tor* 三个APP配置。
Defense implications
- Confirms Freegate, Psiphon3, and Tor each have dedicated app-ID signatures in TSG, tracked with per-tool active-IP reporting — these three tools' current traffic signatures should be treated as known-detected against Geedge-based censors.
Related findings
Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.
TSG implements heuristic tunnel-protocol detection distinguishing Teredo (IPv6-over-UDP, default port 3544) from GTP tunneling based on UDP payload inspection, used to decide 'innermost' session attribution for firewall matching.
Internal engineering docs detail MAAT's config/policy hierarchy (region/policy-unit -> group/policy-object -> compile/policy, a conjunctive-normal-form structure capped at 8 top-level groups), its Redis-backed one-master-many-replica config push ("MAAT Redis") with a rulescan fallback, and confirm MAAT runs non-distributed -- one instance per front-end traffic-scanning box -- invoked by sapp per-packet or per-stream (Maat_stream_scan_string_detail) with match-all-then-return semantics; recommended hardware is CentOS 7, 256GB RAM, 2TB disk, 48-core Xeon E5.
TSG runs two separate detection engines: a licensed third-party DPI engine for general app/protocol identification (requires per-environment authorization -- absent in a demo environment caused a detection gap), and a Geedge-built component ('glimpse_detector') specifically for VPN protocol identification (WireGuard, OpenVPN). App-ID numbering (e.g. built-in wireguard=3700) can be silently shadowed by environment-specific custom IDs, causing detection to fail even when the underlying protocol is correctly classified.
A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.
As of TSG's SSL/protocol parser in 2022, in-band STARTTLS negotiation (observed via XMPP) was not supported by the SSL parsing logic, causing app-identification-based blocking to silently fail for STARTTLS-negotiated sessions; the workaround was a manual TCP-payload string match rather than proper protocol classification. Confirm current status before relying on this -- single 2022-dated ticket, may since be patched.