A TSG-Application blocklist test found that disabling Facebook/Twitter in TSG's per-app policy did not stop Psiphon3 traffic from reaching those services in practice, because Psiphon3's dual-stack fallback drove the tunneled Facebook traffic over IPv4 QUIC, which TSG's classifier failed to attribute to Facebook -- in contrast to Taobao/Bilibili/Youku/JD, which TSG blocked successfully in the same test.
禁用facebook后，Psiphon3 v6获取了facebook的v4 和v6地址，但后续通信是通过v4进行连接，TSG 未能从ipv4 QUIC中识别facebook
Defense implications
- This is a named, concrete detection gap: TSG's app classifier did not reliably attribute IPv4 QUIC flows to Facebook in this test, even though it correctly blocked the same app over other paths. A transport that prefers IPv4 QUIC as its outer protocol may inherit this blind spot against this TSG ruleset snapshot.
- This is a single dated test against one TSG build/ruleset -- AppSketch/TSG signature updates ship on their own cadence, so treat this as a lead to re-verify currency on, not a standing guarantee.
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.
A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.
MESA_Platform's "quic" module (built and packaged as stellar-on-sapp/sapp RPMs) implements SNI/User-Agent extraction from both cleartext GQUIC (versions 23-59) and encrypted IETF QUIC RFC9000 ClientHello payloads, and supports a QUIC SNI whitelist -- i.e. the DPI pipeline decrypts/parses encrypted QUIC handshakes to recover the destination domain rather than being blocked by QUIC's encryption.
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.